httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r1397320 - /httpd/httpd/trunk/modules/dav/main/util.c
Date Sun, 14 Oct 2012 12:00:11 GMT
On 14 Oct 2012, at 1:01 PM, Christophe JAILLET <> wrote:

> Sure.
> What is the procedure for backport proposal ?

The general idea in the httpd project is that trunk is "commit then review" (CTR), and the
various branches that we release to people are "review then commit" (RTC).

What this means practically is that on trunk, people commit to trunk and then everyone else
reviews the changes (as you have done so far). On the branches, like v2.4, we do the opposite,
so what you need to do is ask that everyone review your proposed change to the branch in advance,
and if you get three +1 votes (including your own, usually if you propose a change you'd also
vote for it, but you must do so explicitly), you can then apply the very same change to the
older branch.

How this happens is that in the branch, we maintain a STATUS file, part of whose job it is
to keep track of who has proposed a back port, and whether it has achieved the three +1's

Scroll down in the file, and you'll see a section marked as follows:

  [ New proposals should be added at the end of the list ]"

Add your back port proposal to the end of this list, for example, this is the last one added
most recently:

   * "Iterate" directives: Report an error if no arguments are provided.
     trunk patch:
     2.4.x patch: trunk patch works
     +1: trawick

What the above has said is that trawick has proposed that revision 1397172 from trunk be backported,
and that the patch applies clean to v2.4 without modification ("trunk patch works"), and he
has given his +1 vote to go ahead. What he is waiting for are two other people to evaluate
the patch, agree that it should be backported, and once we get to 3 votes, actually do the
merge to the v2.4 branch.

You may find your patch sometimes doesn't apply cleanly to v2.4, because the v2.4 code is
slightly different. In these cases you need to create your own patch that applies to v2.4
with all conflicts and differences accounted for, and provide that. That is what happened
in this example, where the trunk patches and the v2.4 patch are different.

   * mod_ssl: Work correctly with a development version of OpenSSL.
     trunk patch: and 
     2.4.x patch:
     -1: kbrand: breaks OS X builds, superseded by approach based on MOD_CFLAGS etc.

After testing out your proposal, people might agree with it, or people might find a problem.
In the example above, kbrand uncovered a problem and voted -1.

At any time you might go through the proposals in STATUS, apply them to your v2.4 code checkout
and evaluate them, and then vote accordingly as to whether you agree or disagree with the
change. The way you do that is to modify the STATUS file accordingly, and then commit your
changes to the STATUS file.

What should get backported? There is an expectation from the end users of httpd that it is
safe to move from v2.4.3 to v2.4.4 at any time. What this means practically is that it is
generally bug fixes or new features that get backported, but changes that would break people's
existing configurations such as wholesale rewrites or major changes aren't backported.

The reason I believe the small fixes should be backported if possible is that it reduces the
chance that future patches proposed for backport by others will conflict, meaning that more
often than not, "trunk patch works" will be the case.

Some changes don't require votes for backport. Fixing a spelling mistake in a comment for
example has no functional effect on the branch's code at all, and so is safe to backport without
voting. The same with changes to something like the build system on a particular platform
where there aren't enough maintainers of that platform to get 3 votes. When in doubt, propose
the change in STATUS is the safest way to go.

So to sum up:

- Modify the STATUS file in v2.4.
- Add your proposed backport at the bottom of the list of proposed backports.
- Vote for your change.
- Commit STATUS.


View raw message