Re: policy for pushing changesets

[Jordi Gutiérrez Hermoso]

On 11 April 2011 21:14, Ben Abbott <address@hidden> wrote:

> I attempted to merge this Changeset.
>
>        hg update -C default
>        hg merge stable
>
>  and encounter conflicts with the ChangeLogs. I'm given the option of ...

The ChangeLog are gonna be particularly problematic with the new
workflow, since they are linear but the workflow isn't, and neither is
any other file in the source tree. ChangeLogs are really a remnant
from the days when *no* VCS was used for a project, but nowadays the
ChangeLog is in the VCS's history.

If this isn't too much rabble-rousing, I think this is a good time to
adopt a new policy: hg commit messages should contain the details that
the ChangeLogs used to have, roughly in the same format; we keep the
ChangeLogs around for archival purposes, and we extract information
from the "hg log" command in order to generate future ChangeLogs for
tarball releases. Other than avoiding duplication of information (most
of us were writing almost the same thing in the hg commit message as
in the ChangeLog anyways), this also simplifies the workflow plus
avoids the problems of having to explicitly mentioned what files
changed. The boring administrative details of who changed what files
and when are thus now automated, but the problem is that it's going to
be more difficult now to go back and edit the specifics of a commit
message. Be aware of that limitation. We might have to live with typos
and spelling errors in commit messages.

Anyways, do we really want detailed comments of every boring little
change in tarball releases? ChangeLogs in tarball releases are also
from a time when individual changes were larger to the point where
each was a minor version change. Nowadays, we make much smaller and
frequent changes. Anyone who is interested in every detail can read
the hg log, and everyone else can get the broad overview from the NEWS
file in the source release.

How does this sound?

- Jordi G. H.