Format for JDK 6/7 changeset comments?

[Kelly O'Hair]

Mercurial changesets should not be created until the change has been reviewed
and is ready to be integrated into a public area.
Changes that are untested, unreviewed, or experimental should stay as patches,
at least that's my opinion after using Mercurial for some time.
If we allow completely unreviewed and untested changesets into the repositories,
we run the risk of severe changeset clutter. They don't have to be perfect,
but we need some kind of quality control on them.

People need to try the mq extension (myself included), which may provide some
answers here.

And the notifications of changesets that have been integrated can include the
diffs, but when you can easily and quickly browse the changeset, I'm not so
sure you need to send all the diffs.  But that's a changeset notification issue,
not a changeset comment format issue.

-kto

Andrew Haley wrote:
> Kelly O'Hair writes:
>  > I agree.
>  > 
>  > The more you put in the changeset comment, the higher the odds that
>  > there will be mistakes in those comments, mistakes that can NEVER
>  > be corrected.
>  > I favor keeping it short and sweet, and use the bug database for
>  > all other information.  A place that can be corrected and added to
>  > over time.
>  > 
>  > Of course the bug database needs to refer to the changeset, which
>  > IS the true source of the change. Any webrevs and diffs in the bug
>  > database should probably be removed once a changeset is public, or
>  > perhaps multiple changesets depending on how many it takes to
>  > really fix a bug. You don't want incorrect diffs or webrevs
>  > floating around when the true change is in the changeset.
> 
> Hmm.  Does this mean that the checkin comments are not written until
> after the reviewer has done their work?  That seems wrong.  In gcc we
> write the change log entry when we submit a change.
> 
> Also, IMO the supplemental information about the bug should be
> automatically copied into a mailing list as part of the same thread to
> which the change itself was copied.  That way, you only need mailing
> list searching software to find everything.  It would be better not to
> depend on the bug database in order to find out why something has
> changed, or indeed what has changed.
> 
> Andrew.
>