On Wed, Aug 31, 2011 at 13:51, Hannes Magnusson <hannes.magnus...@gmail.com> wrote: > On Thu, Jul 21, 2011 at 23:11, Hannes Magnusson > <hannes.magnus...@gmail.com> wrote: >> On Jul 21, 2011 9:12 PM, "Adam Harvey" <ahar...@php.net> wrote: >>> On 21 July 2011 12:07, Hannes Magnusson <hannes.magnus...@gmail.com> wrote: >>>> On Thu, Jul 21, 2011 at 20:14, Adam Harvey <ahar...@php.net> wrote: >>>>> On 21 July 2011 07:15, Hannes Magnusson <hannes.magnus...@gmail.com> >>>>> wrote: >>>>>> A (short) list of "authors" or a "group" needs to exist due to licensing >>>>>> issues. >>>>>> How to generate that one I've no idea. >>>>> >>>>> Are you sure about that? I think you'll find that copyright is held by >>>>> all contributors individually, so it's actually more accurate to point >>>>> to the entire list for licensing purposes. >>>> >>>> That would mean we would need the approval of every single person in >>>> that gigantic list to change the license. >>>> It was hard enough to track down and contact the less-then-10 people >>>> lasttime >>> >>> Yep. That's why Wikipedia had to get the GFDL changed to allow them to >>> convert to CC — it was the only feasible way of doing it, since they >>> couldn't contact all their contributors. >>> >>> It is a pain. >> >> Right. Therefore having a little group of some sort makes that epic >> pain into "just" much annoyance. >> >> >> >>> >>>>>> I would like a "NEWS"/"ChangeLog" listing, similar to what php-src does. >>>>>> That would serve the dual purpose of improving crediting of people >>>>>> actually working on the docs on daily basis, and letting the user know >>>>>> what is new within the docs (so he can pay attention to modifications >>>>>> to his favorite doc page), and bugfixes etc etc. >>>>> >>>>> It would be nice. We should be able to auto-generate something, >>>>> really, based on commits. >>>> >>>> >>>> I don't like the idea of autogenerating such list. The black list >>>> would be painful to manage (i.e. how would remove WS commits and >>>> random weirdness?) >>> >>> I wouldn't even try to. They're not that big a percentage of our commits. >>> >>>> I'm sure it will take few weeks to get used to update a "NEWS" file on >>>> every bugfix/new additions, and drive-by-committers will probably not >>>> to do.. but in the longterm I still think its a better option. >>>> >>>> We could then manually rotate the list every once in a while, or even >>>> create a rule in PhD to only list the last "100 entries" or whatever. >>> >>> How's this going to integrate with the online doc editor? >> >> >> I suppose in the first few weeks you'd have to manually edit the file. >> Afterwards we could add, on committing, "what do you want to have as >> NEWS entry?" or when creating the patch or whatever. I'm sure we can >> come up with something. >> >> As for the presentation, I'd like it to be displaid on the frontpage >> somehow, and on the rendered page itself, and on >> php.net/manual/en/whats.new.in.the.docs.php or something along that >> way. >> >> The news entry could be contain the bug#, date, message, xml:id and username. >> That way we could easily show the "edits to this page within the last >> month (plus comments)", aggregate "who makes most bugfixes" and "other >> modifications" and whatever.... > > Attached is a patch that adds a changelog to the manual. > The initial list of entries is extracted from svn log, any commits as > of "now" should be manually added (and the initial list probably > modified). > > The patch adds a paragraph to the manual frontpage with a link to the > changelog, which is implement as an chapter under the PHP Manual book > (which currently only contained preface). > > I dropped the idea of adding xml:id to the changelog entries (what if > you edit bucketloads of files?), but we could do that later and expand > more upon the idea. > As for phd, it just prints this out in a table. > Later on I would like to create some sort of paginated list, or simply > drop entries older then X months. > Furthermore, adding links from the username entry to people.php.net > would be fun, and automatically scanning the message for "fixed bug > #xyz" and link it to bugsweb etc etc etc. > > > So. > Every changelog entry should look as follows: > <revision> > <date>2011-08-31</date> > <authorinitials>bjori</authorinitials> > <revremark>Fixed bug#xyz</revremark> > </revision> > > The current <revremark> entries are extracted from the commit > messages, but it would be nice if we could make them "audience > readable" when we start adding changelogs manually. > > Since this requires modifications in PhD (to support the revision, > authorinitials and revremark elements) we'll need to roll out a new > PhD release before being able to deploy this, I do however intend to > commit the manual-changelog.xml file (without enabling it in the > build) so we can start populating it.
So.. I never did commit that file.. but I never got any feedback on this whatsoever either. The current PhD release supports this now btw. Anyone that cares? -Hannes
