KDE 4.1 Changelog?

[Robert Knight]

Hi,

> To be honest I prefer XML over "simple text-based" since I've never 
> really understood the standard text-based ChangeLog format. The XML in
> this case is really not hard to understand or too unwieldy IMHO.

Fair enough, the file format issue is debateable and XML does have its
advantages.  It would make merging easy I suppose.  As long as the
schema is simple.  As I said before, I think the main problem is that
the ChangeLog is kept in a completely different part of the tree from
the code for the application.

If the logs were at least kept near the code (in whatever format) I
think they would get more attention.  Plus it would make it possible to
do a simple scan through the tree looking at the last commit dates of
the logs for each application and nag/bug/ping/poke the right developers
for out-of-date logs.

A general call to "update the changelog" gets posted each cycle but
unless specific apps are singled out it is easy to ignore.  I know I
tend to make a mental note of this kind of email and then forget about
it.

> We'd need to comb through the svn log anyways, and I think we'd get
> a better ChangeLog if developers put a little bit of work toward
> updating their part of the ChangeLog instead of having a couple of
> people poring through the svn log between each release.

True, it won't catch every fix but presumably everything marked with
BUG:XYZ should be accounted for.  For those of us using git/bzr etc.
locally getting a list of bugs fixed between two releases is trivial.  

> Perhaps we can make that easy by making a tool
> to add the commit message to the ChangeLog automatically.

As Maks said earlier, commit messages can be quite technical.  I see the
ChangeLog as something which should be mostly readable by a KDE-aware
audience (keen users, packagers, developers of other KDE projects,
people involved with non-development areas of KDE) who might not
actually understand the inner workings of a particular project.  For
this audience, it is quite useful to be able to see changes separated
into optimisations/features/bugs etc. at a glance - much like the Commit
Digest.

The ideal flow of work might go something like this:

1.  Get raw KDE 4.X <-> 4.(X+1) changelog for application Foo (from SVN)
as a reference.
2.  Developer summarises into local changelog (might happen during or at
the end of a cycle)
3.  Script combines all the app changelogs together at the end of a
cycle.
4.  Publicity team use the combined output to put together a pretty
guide for KDE 4.(X+1)

> I will volunteer to merge the Feature Plan into the XML
> changelog if that's the route we're taking though.

I always think the feature plan has been somewhat detached from reality
in many parts of KDE for the same reasons.  


Regards,
Robert.

On Tue, 2008-06-03 at 18:36 -0400, Michael Pyne wrote:
> On Tuesday 03 June 2008, Robert Knight wrote:
> 
> > Updating a single XML changelog which is kept in a completely
> different
> 
> > part of the tree from which individual developers normally work is
> an
> 
> > awkward process. I think this explains why it rarely seems complete.
> 
> Well before it was a .php file which developers had to maintain in the
> same awkward directory, so this is at least progress. :-/
> 
> > gnomies keep a simple text based ChangeLog file in the root of each
> 
> > project and then run a script to build the final log (in whatever
> 
> > format). That would probably get better results. Plus it would be
> 
> > easier to automatically ping the right developers to provide an
> 
> > up-to-date log.
> 
> >
> 
> > I presume there are reasons why an XML file was chosen, can anyone
> 
> > enlighten me?
> 
> To be honest I prefer XML over "simple text-based" since I've never
> really understood the standard text-based ChangeLog format. The XML in
> this case is really not hard to understand or too unwieldy IMHO.
> 
> > > 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? 
> 
> Even if we not, not all bug fixes go against a reported bug. We'd need
> to comb through the svn log anyways, and I think we'd get a better
> ChangeLog if developers put a little bit of work toward updating their
> part of the ChangeLog instead of having a couple of people poring
> through the svn log between each release.
> 
> Perhaps we can make that easy by making a tool to add the commit
> message to the ChangeLog automatically.
> 
> i.e. a
> 
> CHANGELOG:product=juk field that we could add with BUG, FEATURE, etc.
> 
> I will volunteer to merge the Feature Plan into the XML changelog if
> that's the route we're taking though.
> 
> Regards,
> 
> - Michael Pyne
>