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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel