apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: backports/merges
Date Mon, 09 Apr 2012 07:41:55 GMT
On 08.04.2012 15:28, Jeff Trawick wrote:
> Perhaps it is just my nature to disagree with everybody when there is
> some contentious discussion.  Or just possibly it is my nature to try
> to pull apart what was discussed (or yelled), throw away the most
> extreme aspects, and see if there is anything to agree on.  (Even in
> the absence of past success at doing so :( )
> Procedure:
> Below is what I observe and practice for changes made to the stable
> branches, and I believe this is clearly the widespread, accepted
> pattern.  Furthermore I believe it is simple enough that it can be
> followed without demands for documentation, even though such
> documentation would be fine.
> Commit to trunk.
> Commit to 1.9.x, 1.8.x, 1.7.x, etc. down to the actively maintained
> stable branch. In cases where the actively maintained stable branch
> has recently changed, it is up to the committer to decide whether to
> commit to the previous actively maintained stable branch.  (There is
> at least limited value in having the project decide what the patch for
> some branch is even if there are no clear plans to release it.)
> Commit messages for the branches always explicitly reference the trunk
> revision, not relying on mergeinfo, which does not show up in normal
> views of revision history.
> Modifications expected to remain only in trunk, at least for some
> time, should be accompanied by a CHANGES entry in trunk, if
> appropriate.  CHANGES entries are appropriate for user-visible changes
> to a previously released feature or for user-visible feature
> additions.
> When committing to previously released branches, the CHANGES entry
> should be part of the commit, whether or not it was part of the trunk
> commit.  (A CHANGES entry is commonly omitted from the trunk commit if
> a backport will be performed almost immediately.)
> Do you disagree with the procedure and/or my attempt to describe the
> "normal" way this is handled?

No, I agree and I think it is more useful to include the CHANGES entry 
in the backport commit than to split it in a second commit. At least 
that's what I tried to do in the past influenced by following the list 
and commit messages. Sometimes the CHANGES entry either is forgotten 
during the backport commit or postponed by a differing personal 
preference and is then added soon as a separate commit which I think is 
less useful but still acceptable.

> a. Did I misrepresent the project norms?  Please follow up to this thread.
> b. Do you believe it should be done differently, irregardless of
> project norms?  Please propose something different in a new thread.



View raw message