On Jun 4, 2010, at 1:58 AM, Ruediger Pluem wrote: > On 04.06.2010 01:51, Graham Leggett wrote: >> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote: >> >>> It would be, but it's necessary. The ASF is a collaborative environment; >>> unreviewed code should not released, even when the authors are >>> committers. >>> A major patch like this hitting svn, without previous review, makes our >>> fellow committers' eyes glaze over. >>> >>> If there is not positive feedback from two reviewers, this code does not >>> belong in trunk/. As a committer, you are *free* to create your own >>> sandboxes in svn to demonstrate code changes, if that helps attract the >>> necessary review. >> >> What you're describing here is review-then-commit (RTC). > > No. It was always the case that larger and more intrusive changes should be > discussed on dev@ before folding it into trunk either by posting them or by > creating a developer branch. > This makes perfect sense to me as we are doing a collaborative effort in > creating the code and it shows that there is enough support for these > kind of changes. It helps avoiding a large back and forth in the trunk > and -1 votes on commits. > I don't think that we need any kind of written policy for this as I trust > the developers here to do it if it is needed.
In reality, this issue exists because we are using trunk currently as the "code sandbox", which should be CTR as well as the direct descendent for 2.4 and, as such, should be treated more gingerly and thus RTC. We could easily resolve this by creating another branch... either copying trunk to httpd-2.3 and keeping trunk as CTR and having 2.3 as RTC (ala 2.2), with the expectation that 2.3 becomes 2.4, or else some sort of sandbox branch off of trunk for more "intrusive" changes... Personally, I think branching a 2.3 would result in a faster push towards 2.4.
