Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of rainer.jung@kippdata.de
 designates 195.227.30.149 as permitted sender)
Message-ID: <4F8292C3.2000805@kippdata.de>
Date: Mon, 09 Apr 2012 09:41:55 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: backports/merges
References: 
 <CAKUrXK7NMJr1uJG-=ds69vEyWvV86bswahbobspETEng1i-=QQ@mail.gmail.com>
In-Reply-To: 
 <CAKUrXK7NMJr1uJG-=ds69vEyWvV86bswahbobspETEng1i-=QQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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.

Regards,

Rainer