Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.220.178 as permitted sender)
MIME-Version: 1.0
Date: Sun, 8 Apr 2012 09:28:04 -0400
Message-ID: 
 <CAKUrXK7NMJr1uJG-=ds69vEyWvV86bswahbobspETEng1i-=QQ@mail.gmail.com>
Subject: backports/merges
From: Jeff Trawick <trawick@gmail.com>
To: dev@apr.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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?

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.