apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: backports/merges
Date Mon, 09 Apr 2012 13:09:03 GMT

Rainer Jung wrote:
> 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.




View raw message