On Wednesday 10 July 2013, William A. Rowe Jr. wrote: > Jim Jagielski <[email protected]> wrote: > > In any case, I *am* concerned that w seem to have quite a bit of > > difficulty in getting 3 +1s a lot of the time and that the > > backport process from trunk to 2.4 is becoming more and more > > painful. [...]
Jim, I think you are particularily affected by that problem because you hack a lot on mod_proxy, which is a complex beast. Of the few active committers, not all are comfortable reviewing changes there. The same is probably true for Graham and mod_cache. > What I am asking, is whether that trunk is a sandbox to hack in, or > whether is is approaching a releasable state? I'm asking, whether > trunk is a worthwhile exercise or a distraction and complication to > fixing and enhancing the shared, released project code, > branches/2.4.x? trunk is needed for changes that break API/ABI compatibility. And I think it is also very useful for complex changes that take time to get into a releasable state. If you take that away, the result will be that branches/2.4.x-renamed-to-trunk will not be always in a releasable state, because it will contain unfinished/broken changes. This may deter people from volunteering as RM because they would first have to clean up the mess by fixing open issues or reverting changes. And the quality of 2.4 releases will probably suffer, too. The same is true if we make 2.4 completely CTR or the 72 hour scheme proposed by Jim. But I would be open to CTR 2.4 for some classes of changes, maybe simple bug fixes with no (public or private) API change, or for changes that have reasonable test coverage in the test framework. WRT 2.5/2.6, I very much hope that it will not take as long as the 2.2->2.4 cycle. I am pretty sure that we cannot reasonably support SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable future.
