On 14 Oct 2012, at 1:01 PM, Christophe JAILLET <[email protected]> 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 required: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/STATUS Scroll down in the file, and you'll see a section marked as follows: "PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ 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: http://svn.apache.org/viewvc?view=revision&revision=1397172 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: http://svn.apache.org/viewvc?view=revision&revision=1358167 and http://svn.apache.org/viewvc?view=revision&revision=1358168 2.4.x patch: http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch +1: -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. Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
