IcedTea6 1.6 Released!

[Mark Wielaard]

On Thu, 2009-09-10 at 16:44 +0100, Andrew John Hughes wrote:
> 2009/9/10 Andrew Haley <aph at redhat.com>:
> > Andrew John Hughes wrote:
> >
> >> I'm not suggesting using it as the sole basis for merging; that would
> >> be wrong as you say.  But having a summary line better than 2009-08-27
> >>  Matthias Klose  <doko at ubuntu.com> or 2009-09-09  Andrew Haley
> >> <aph at redhat.com> would mean you can make a more educated guess as to
> >> whether it's worth looking at the entire changeset.
> >
> > Sure, it's better for the person merging, but even more admin for the
> > person committing.  I think we have quite enough procedural rules without
> > this.
> >
> I don't think one line is a major grievance, and we don't really have
> any more rules than post your patch from approval and including the
> changelog entry in your commit message.
> 
> >> You're always going to get this 1-line summary regardless, it would be
> >> good to have it as something sensible.
> >
> > It would be nice, but every time we add more things that a committer
> > must do we make it harder for people to contribute.  This one isn't
> > worth it.
> >
> That depends how happy you are with changesets being missed.  Our
> current standard for commit messages currently makes that far more
> likely than it would be otherwise.

I strongly agree. And we could formulate it as making it less work for
the committer. Just leaving off the duplicated first line that contains
the name and the date would already be a great improvement, and one less
line to type for the committer!

Also having a consistent format of the first line so that all output
looks identical (say just bug id if available plus a summary < 80 chars
of what is being fixed) would make it much easier to would safe (at
least me) lots of time going through a hg log or mercurial web search.

Note that it could then also be used to make an automatic list of items
for the release announcement.
hg log -r icedtea-1.6:tip --template "{desc|firstline}\n"
Sure it would still need editing by hand, but having the bug id and
summary for each commit would make the life of the release master much
easier imho.

I really like how Xiomara automated this from the summary lines for jdk7
releases by just grabbing the hg rev, the bug id, adding a link, plus
the summary line to give a quick overview of what changed:
e.g. http://download.java.net/jdk7/changes/jdk7-b71.html
I would love to do the same for IcedTea if we agreed on a similar
format.

Cheers,

Mark