On Wed, 10 Jul 2013 20:20:22 +0200 Stefan Fritsch <[email protected]> wrote:
> On Wednesday 10 July 2013, William A. Rowe Jr. wrote: > > > 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. I am not proposing to eliminate these. I am proposing that these be parceled into sandboxes, until such time as we are ready to create a 2.5.0-alpha release. That time doesn't seem to be right now. The advantage is that each change can be reviewed and enhanced in its own right by anyone (literally, we have opened the sandbox to all ASF committers, right?) By ensuring each developer who is either breaking changes or offering a complex patch shepherds the change into 2.4.x or a future 2.5.0-alpha trunk candidate, we will ensure they don't languish and become troublesome debugging efforts when they are finally noticed by the -alpha testing community, some year or years after they are first committed. These can certainly be tracked in STATUS. Sandboxes are useful things (as I suggested, this could become a whole svn vs. git debate, but the mechanics are similar enough to avoid that discussion for now). I'd maintain that working around 'future ABI breaking proposals' today by all of the committers, rather than simply by the patch's champion(s), is imposing unnecessary complexity on the rest of the project. > 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 converse is also true. If 2.4 is 'broken', that is where most of our eyes are at (that, and 2.2, hopefully everyone has fun rm -rf'ing their 2.0 checkouts this week :) Such breakage is unlikely to last. The rules of CTR are pretty specific about big breaking changes - we propose them to the list first. Better yet, submit them as a sandbox where others can debug them. Then svn cp them into place when the devs agree we are ready for the change. But discussing the small changes, were it simply CTR, then that review simply happens. If you don't like the change, you need to respond and watch development. While the changes sit in a non-release /trunk/ they are ignored at the time they are authored. Even the author may forget where they were going with a patch by the time feedback arrives. With CTR there is an immediacy for reviewers to follow-along with the effort which may revive some participation. Committers are protective of the code they use (or hope to use soon, in the case of the widely-unadopted 2.4), but less so of some intangible code tree that may have little relevance for the next 1-3 years. > 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. That is pretty much what I am suggesting, and believe that STATUS for every minor change is quite a bit of overkill. STATUS is great to point people at major refactorings, new works, ap_mmn bumping changes and the like. > 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. Almost agree, I suspect that would become 3.0 though. But since that is in the distant-foreseeable future and we may be facing new competing solutions to these problems, sandboxes seem like a better solution till some -alpha release is more than a far-off possibility. Once we are rowing together on an -alpha for a near-term 2.6 or 3.0 major release, the current /trunk/ -> backport strategy once again will make good sense. But the code in 2.4.x, while released, is simply not adopted. We don't have the frustrations of 2.0 or 2.2 where they are widely deployed and consumed by many downstream packagers, at least not yet. Bill
