IcedTea6 1.6 Released!

[Andrew John Hughes]

2009/9/10 Mark Wielaard <mark at klomp.org>:
> 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!
>

Unfortunately, the first line after the name/date is not that helpful
in all cases, as it represents only part of the log of changes:

2009-03-09  Gary Benson  <gbenson at redhat.com>

	* ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp

would become:

summary:	* ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp

which isn't that helpful either, especially as that patches touches
many more files.  A summary would be generally helpful as an overview
of the purpose for the change.  With a lot of changes, it's not always
clear.  Better ChangeLog comments could help there too.
When we were tracking down the patches for IcedTea to list on the
wiki, a number were just committed as 'new file' which doesn't tell
you anything about what it does.  Writing good comments that are
useful later is an art, and one we all probably need to improve on.

Yeah this is all more work for the committer, but it makes the whole
repository more maintainable in the long run.

> 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.
>

+1

We should keep the bug ID optional though.  I think Sun's bug ID per
change results in an overcrowded database where the actual real bugs
reported by real users can get lost.

> 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.
>

Good idea.  Then we'd be less likely to miss things like the change to
--with-openjdk (*ahem*)

> 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.
>

I like the pages Xiomara publishes and I regularly use them for
updating IcedTea7.  They've proved invaluable on many an occasion.

> Cheers,
>
> Mark
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8