: - Need to define all developers/committers in front and assign each an ID,
: and use this ID when referring to them. I guess we can ignore this practice
...
: Person2). And BTW, AFAICT for now it does not support that P1 via P2 concept
: (though that can be requested as a new feature).
adding new committers to this list wouldn't be that bad ... it's not like
we have exponential growth of committers.
listing out all *contributors* would be a pain, but i think just ending
each descrption with "Patch courtesy of John Doe" instead of our current
"via" would probably be fine.
: The status.xml that needs to be maintained can be reviewed in
: http://people.apache.org/~doronc/status.xml - only two issues there now, but
: one can get the picture what it would take to maintain this file.
is the "type" attribute mandatory? the gifs it produces are kind of
anoying, and it seems to be somewhat reducndent with teh types of sections
(ie: contexts) we use ... then again, we could always start using "type"
for things like "new functionality" "updated api" etc, and make hte
contexts more specific to the code module (ie: one for each contrib, one
for search functionality, one for indexing functionality, one for
documentation, etc...) ... although that would make it harder to get an
overview of "what are the big changes" unless there are options for how ot
change the rendering of the file.
: To me the main disadvantage of using this is the need to run forrest with
: every commit to review the updated changes.html/pdf which I think is almost
: too much. Personally I am not very fond of editing XML files, but perhaps
: others are. (Editing the html file is not as simple as editing the txt file,
: but still I think way simpler than the XML.)
:
: So my preference so far is the HTML version, with a stylesheet(s).
we wouldn't neccessarily need to run forrest on every commit ... the
authoritative XML would be in SVN, and it's not too complex to read -- the
nightly builds would have the generated HTML/PDF versions (or do they?
does the nightly build run forrest or just assume people have commited the
generated docs? ... we can make the nightly build run forrest if it
doesn't already), and we could always include XSLT declarations in the XML
file so that peopel viewing it in a relatively modern browser would see it
as pretty HTML (which could have the same CSS/collapse type functionality
you describe)
not that i'm particularly fond of this status.xml fomat ... i'm just
throwing these ideas out there. Any well structured XML/XHTML format
would let us generate all sorts of views on the changelog using
stylesheets, the forrest version just has the nice bonus of integrating
well with our other documentation (in terms of left nav and style and what
not)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
