-----Original Message----- From: Eli Collins [mailto:[email protected]] Sent: Friday, September 09, 2011 10:03 AM To: [email protected] Subject: Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
... > MR1 is being maintained on 20x. In fact 20x is the only MR1 code that > supports security and disk failure handling. The MR1 code in 22 is a > regression in some significant aspects (features, performance, bugs) from the > latest stable MR1 (204). ... Eli, aside from the disk failure handling which is a new feature in 205 (not present in earlier 20x releases), could you please elaborate on which other significant aspects 22 would regress from 20x? > My understanding of the way Apache operates is that you can't do things like > "declare blocks on upgrade paths". People can try to release updates to 21 or > 22 (or some new tree). Ie the decisions are made implicitly by where people > invest cycles. If a group of committers say that they'll commit to trunk, to 0.23 and to 0.20x, but not to 0.22, then in effect that is like to "declare a block on upgrade path" isn't it? The more such commits that go in to other branches, but not the ones in between essentially is a declaration of a block, because of the very regression argument you make. I agree that nobody can be made to contribute to something they don't want, but does that result into a split? In other words, if a significant bug fix or feature goes into trunk and into 22, can developers then simply say: "I'm not interested to put this into 23, you do this yourself if you want?". Will that be tolerated or vetoed? Thanks, Joep
