Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates
 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABD8fLU6YaLz_oe5zB9njjZgT0vJ=vCyh8NzX9Q2-=k44LgsJQ@mail.gmail.com>
References: <20120401152345.D155F238897A@eris.apache.org>
	<CABD8fLU6YaLz_oe5zB9njjZgT0vJ=vCyh8NzX9Q2-=k44LgsJQ@mail.gmail.com>
Date: Sun, 1 Apr 2012 17:04:52 -0400
Message-ID: 
 <CAKUrXK638CJfaBTydHCmvwXC1ZZ-T46QeVQDcsJ1BH1AcyUSiw@mail.gmail.com>
Subject: Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./
 CHANGES crypto/apr_crypto.c
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein <gstein@gmail.com> wrote:
> On Sun, Apr 1, 2012 at 11:23, =A0<minfrin@apache.org> wrote:
>> Author: minfrin
>> Date: Sun Apr =A01 15:23:45 2012
>> New Revision: 1308135
>>
>> URL: http://svn.apache.org/viewvc?rev=3D1308135&view=3Drev
>> Log:
>> Backport:
>> apr_crypto: Ensure the *driver variable is initialised when a statically
>> compiled library is initialised for the first time.
>>
>> Modified:
>> =A0 =A0apr/apr-util/branches/1.4.x/ =A0 (props changed)
>> =A0 =A0apr/apr-util/branches/1.4.x/CHANGES
>> =A0 =A0apr/apr-util/branches/1.4.x/crypto/apr_crypto.c
>>
>> Propchange: apr/apr-util/branches/1.4.x/
>> ------------------------------------------------------------------------=
------
>> =A0Merged /apr/apr/trunk:r1308131
>
> -131 has no edit to CHANGES.
>
> When performing backports, you should commit *just* the backport. If
> you want to make other changes, then keep them in a separate commit.
>
> Combining changes like this is poor branch policy. It means that we
> can no longer trust that a backport is *JUST* the backport. We have to
> investigate to determine whether other changes were made in the
> commit.

That adds an extra step to looking at the code changes for a CHANGES
entry, if indeed the merger/backporter remembered to list the code
change in the CHANGES commit.  (Otherwise it is more painful.)

I guess you mean that the "trust" part comes not from backports in
general but only from a a "touchless" merge.  Generally a "backport"
may require minor changes to reflect other differences in the branch.