On Wed, Jul 10, 2013 at 2:03 PM, Jim Jagielski <[email protected]> wrote:
> Pulling this out as a proposal: > > I propose that we track all backports in 2.4 STATUS as we currently > do. Each backport is time-tagged and we operate under a lazy > consensus. Assuming no -1 votes within 96 hours, the backport > can be applied to 2.4.x. If the backport gets 3 +1 votes sooner > than that, then it can be applied asap... > > As with ALL patches, any commit can be reverted for good > technical (or legal) reasons. > > [ ] +1: Agree with this proposal (to start post 2.4.5 release) > [ ] -1: Disagree with this proposal (and why) > > -1 The current process * works well/appropriately IMO; to me that means pretty good stream of fixes to 2.4.x without too high a risk of regressions * has demonstrably resulted in a reasonably small number of regressions so far across 2.4.x and earlier releases (definitely not zero regressions, but pretty darn low). I think that it is a safe assumption that there will be code changes in stable releases that have had less review if we make this change. Largely regression-free stable releases are of crucial importance for infrastructure software like httpd, more so than getting another window-size worth of fixes into the release, especially if they've been looked at less than the others. If I count right, 80% or more of the fixes potentially in 2.4.next are already there (I didn't count mod_lua.) That doesn't seem so bad. -- Born in Roswell... married an alien... http://emptyhammock.com/
