On Wed, 10 Jul 2013 21:30:30 +0200 Graham Leggett <[email protected]> wrote:
> > Can you explain the current rush to release trunk a mere 18 months > after we've released v2.4? I don't see the urgency at all. Graham, thank you for reiterating my point :) /trunk/ is simply premature and an unnecessary obstacle to contributing to 2.4.x, so long as there is no plan to release 2.5.0-alpha. > I also don't see any "mental gymnastics" going on, what I see is our > Review Then Commit process under strain because of a significant > amount of activity on trunk. I believe this is not a problem, > activity is good. Except that trunk is not 2.4.x and will continue to drift. The question before us is whether such drift should be on the contributors of the patches which cause drift? Or on each and every contributor to compensate for that drift? > Stability is good. I don't want the stuff going on in trunk to hit > the stable branch without those 3 +1 votes, even if the wait is > painful. I will agree with you once 2.4 reaches adoption. IBM released 2.0.16 and of course struggled to keep it looking anything like 2.0.current, which was impossible before 2.0.36 or 2.0.42. That was a very dynamic and vibrant time period in this project's history. Others shipped around that 2.0.36-2.0.42 period and that is when reversioning rules were changed to lock in additional stability. I don't see the need for excessive votes for stability for code that is not widely adopted. Even a dud release does not concern me, we patch the regression, release and move on. This (ASF) software is non-commercial, free to the public and if it breaks, as open source, they get to keep all of the pieces. But the code under development is not being shared with the public as a release, which is not in line with the charter of the foundation. > If I could wave my magic wand I'd like to see more people get > involved, but then activity generates activity, so this is not a > problem either. And I've suggested (in another thread) that activity on 2.4.x would attract more activity and more active review of the committed code, whereas code relegated to a sandbox or an unreleased /trunk/ will not get as many eyeballs or participation. My 2c US. Bill
