KDE 4.1 Changelog?

Robert Knight robertknight at gmail.com
Tue Jun 3 18:32:54 BST 2008

Hi David,

This is true but given an automatically generated list of bug numbers
and their titles from the bug tracker the developer could go through the
list and fix up the descriptions to something better.  It could save
part of the work at least.

The full warts-and-all changelog is generally not something which is put
in big bold type on the front page of dot.kde.org in any case.  It
serves a couple of purposes:

- A useful source of information which the publicity team can comb
through to produce a release guide.  If a bug description is not clear
then they can look up the bug in bugs.kde.org given the number.

Many projects seem to order the contents of their changelogs by author
but if we're looking to produce a reference for publicity etc. then
sorting by change type (UI, bug fix, optimisation, new feature,
usability etc.) and functional area affected would probably be better*

- A detailed summary of the development activities during the last cycle
which is easier to read than the commit logs.


* Something like:

Version 4.1
	- BUG12345: Fix crash when
	- BUG6789:  Fix button Y not working
	- Make X 25% faster
	- Reduce memory usage when doing X 

	- Re-arrange dialog Y to make it less confusing

	- Add support for Foo file format

Alternatively store the data as XML and then provide a command-line or
GUI tool to print it out as above for ease of reading.

On Tue, 2008-06-03 at 17:08 +0100, David Jarvie wrote:
> On Tuesday 3 June 2008 17:01, Robert Knight wrote:
> > 
> >> when we commit bugfixes
> >> > since they will not be reflected in a 4.0.6 changelog
> >
> > Do we not have any tools to do this automatically from the "BUG: XYZ"
> > commit messages?
> This is not an ideal solution either since (in my experience) bug titles
> are often misleading or to some degree unintelligible.

More information about the kde-core-devel mailing list