simple generation of the release news items (r18476 - htdocs/trunk/news - Fix unstable version warning)

[Geert Janssens]

On Friday 11 December 2009, Christian Stimming wrote:
> Dear Geert,
>
> Am Donnerstag, 10. Dezember 2009 schrieb Geert Janssens:
> > > We also have such a script - the makefile rules for the ChangeLog file
> > > in the top-level directory do exactly this: It downloads the svn log
> > > data from the hard-coded revision and formats it into some text file
> > > by the use of an xslt style sheet.
> >
> > I didn't know that. I have looked at the Changelog script. It is
> >  unfortunately of not much help for generating the news files. It outputs
> >  plain text, in a particular Changelog format.
> >
> > I played a bit with xslt myself and came up with a script that takes 2
> > parameters: $oldversion and $newversion. (eg 2.3.7 and 2.3.8). It will
> > get all the commits that went into release $newversion since release
> > $oldversion and outputs a simple html table with this info. This can then
> > be copy/pasted into the newsfile for $newversion.
>
> thanks for the script - it could be committed in gnucash/util or similar
> once you've finished working on it. However, the release notes are *not*
> identical to "svn log": There are plenty of commits which neither need to
> nor should appear in the release notes, such as "fixed typo" or "added
> forgotten file". Also, we currently don't have any convention on the
> maximum size of the commit message (a fact which I currently abuse to
> copy'n'paste the full discussion into the commit log message, because it is
> the easiest way for me to look up this discussion later.)
>
> In other words: The release notes should clearly contain less text than
> "svn log", but rather mention those distinct items from a user perspective
> which have changed. The commit message list of your script is a nice first
> step to get to such a list, but IMHO it will always need a manual
> extraction of the useful information.  To sum up: The release note list
> should contain much much less text than the svn log.
>
That's what I more or less expected as well. The full changelog is a good 
starting point to create the release notes though. So I will limit my 
scripting to output the log entries in a readily reusable format. The person 
creating the news page can then further reduce the output as he sees fit. 

> > I haven't commited this script anywhere just yet. I'm just playing with
> >  ideas. I will attach the example output. It currently contains revision
> >  number, committer and logmessage. Would that be reasonable information
> > to put in a newsmessage on the website, or do you prefer to keep it as a
> > bulleted list as it is now ?
>
> I clearly prefer a bulleted list, at most with bug numbers where
> applicable, but no more additional information.
>
Ok for me.

> BTW if you write a svn commit message and quote a bugzilla bug number, I
> recommend writing "bug #1234", i.e. with the hash sign in front of the
> number. Our trac website is set up to turn those numbers (those with hash)
> into hyperlinks into bugzilla, just as "r123" is turned into hyperlinks to
> the respective commit log page in trac.
>
I copied the bug title directly from bugzilla and didn't pay attention to the 
# sign, sorry.

I wanted to correct this with:
$ svn propedit --revprop -r18488 "svn:log"
But I am not allowed to do so:
svn: Revprop change blocked by pre-revprop-change hook (exit code 1) with 
output:
Sorry [gjanssens], you cannot change [svn:log]

Geert