The work on the new guide is progressing steadily, but one thing has become apparent. We need to unify our documentation efforts. The manpages proceed on a separate path from the guide docs, and we on the doc team (Maun Suang , Simon Ruderich, and I) think that the man pages should be rewriten in DocBook and then xincluded into the guide reference section, thereby unifying the guide with the manpages. Simon has tested this method of inclusion to hte new guide and it works. Changes proposed: 1) Change macports.conf.5 man page to portconf.5 and include info for sources.conf and variants.conf, or create sources.conf and variants.conf man pages for consistency. 2) Create a trunk/doc/man directory to hold the DocBook man page sources. 3) Modify the guide to xinclude the rewritten man page xml sources. 4) Modify the guide Makefile as necessary, Simon has that mapped out already. 5) After ensuring that the guide and the wiki have within them all the notes from various text files within trunk, delete these legacy documents. base/doc/INTERNALS, trunk, base/HACKING, etc. The goal is one source for a given type of information, be it the guide or the wiki. I think as far as process, the major changes will be: 1) Man pages need to be rewritten 2) Man page formats will look slightly different, not exactly how we're used to seeing them. 3) People other than those on the doc team should make trac tickets against the documentation milestone, unless the changes are trivial. There are naturally exceptions, but similar rules should be followed as with other trunk modifications. This can all happen fairly quickly, as long as we can agree that this is the direction we need to go. Any objections? Mark
On Sep 7, 2007, at 15:25, markd@macports.org wrote:
The work on the new guide is progressing steadily, but one thing has become apparent. We need to unify our documentation efforts. The manpages proceed on a separate path from the guide docs, and we on the doc team (Maun Suang , Simon Ruderich, and I) think that the man pages should be rewriten in DocBook and then xincluded into the guide reference section, thereby unifying the guide with the manpages. Simon has tested this method of inclusion to hte new guide and it works.
[snip] I have also been concerned about the many various places MacPorts documentation seems to live, and am in favor of consolidating as much as possible.
markd wrote:
5) After ensuring that the guide and the wiki have within them all the notes from various text files within trunk, delete these legacy documents. base/doc/INTERNALS, trunk, base/HACKING, etc.
I think it would be good to have the traditional README and LICENSE files. Maybe even an INSTALL file, even if all it does is say "look at the wiki" The other ones can be docbookized, but it would be nice if there was an offline copy of the internal documentation included with the source code ? Including code: http://trac.macports.org/projects/macports/ticket/12048 I do think embedded code documentation is better than external, though. (too easy to forget to change the documentation after making changes to the code itself, so it's better if functions are documented inline) --anders
Anders F Björklund <afb@macports.org> writes:
5) After ensuring that the guide and the wiki have within them all the notes from various text files within trunk, delete these legacy documents. base/doc/INTERNALS, trunk, base/HACKING, etc.
I think it would be good to have the traditional README and LICENSE files. Maybe even an INSTALL file, even if all it does is say "look at the wiki"
I agree.
The other ones can be docbookized, but it would be nice if there was an offline copy of the internal documentation included with the source code ?
I'm not sure if by "internal" you are including the guide, but I think that would be a good idea too.
Mark
markd wrote:
The other ones can be docbookized, but it would be nice if there was an offline copy of the internal documentation included with the source code ?
I'm not sure if by "internal" you are including the guide, but I think that would be a good idea too.
With "internal" I meant the documentation regarding the MP code itself, rather than the documentation on how to use it and how to write ports ? (that can go in the guide, which can be a separate webpage / download) As a complement to http://geeklair.net/new_macports_guide/#internals.apis, I have now set up trunk to build tcldoc documentation (with "make tcldoc") assuming that you first "port install tcldoc" for the required program... It looks something like http://tcl.jtang.org/tcldoc/tcldoc/ (i.e. JavaDoc) --anders
participants (3)
-
Anders F Björklund
-
markd@macports.org
-
Ryan Schmidt