On Thu, Feb 18, 2010 at 6:08 PM, Konstantin Shvachko <s...@yahoo-inc.com> wrote: > On 2/18/2010 5:19 PM, Jeff Hammerbacher wrote: >> >> Do we have consensus around rebasing on 0.21? Anyone already testing on >> 0.21 >> who would be upset if the current branch were to be retired? > > Rebasing 0.21 will further delay the release. > In current 0.21 branch there is some 28 blockers, > which will take a couple of weeks to fix. > The rebased 0.21 will add to this more issues, and therefore > more time. Based on the experience I had time to stabilize > the release is measured in months rather than weeks.
I agree that we're probably talking months rather than weeks. However, I see a lot of the stabilization time as a fixed cost regardless of the number of changes. Certainly there is an O(n) component too, but I don't think the stabilization time of a rebased 21 is double the stabilization time of current 21. Maybe more like 30% more? Do you disagree? -Todd > --Konstantin > > >> >> On Thu, Feb 18, 2010 at 5:02 PM, Owen O'Malley<omal...@apache.org> wrote: >> >>> > On Feb 18, 2010, at 3:06 PM, Jeff Hammerbacher wrote: >>> > >>> > I think the community will step up to knock down some of the >>>> >>>> >> blockers once we resolve what should be in the 0.21 release: the >>>> >> current >>>> >> branch, or a rebase on trunk. Do you/Yahoo! have a preference on >>>> >> that >>>> >> front? >>>> >> >>> >>> > >>> > Yahoo doesn't care. Even if we rebase the 0.21 branch, because of the >>> > timing, Yahoo will probably never deploy it. (It take months to push a >>> > release through QA and production testing, as I wrote the security >>> > release >>> > will hit the pipeline this year (code complete in february, first >>> > integration cluster in april, on all production clusters by august). >>> > Yahoo >>> > can't handle another big release until january 2011. >>> > >>> > Personally, I'd prefer to rebase 0.21, especially after we have the >>> > Maven >>> > story straightened out. Generating good poms would be a huge win for >>> > downstream projects. >>> > >>> > One big concern is that backwards incompatibility is a big cost. >>> > Especially >>> > if 0.21 (like 0.19) never gets wide deployment, I'd like to start a >>> > vote >>> > that we don't make any API incompatible in 0.22 relative to 0.20. >>> > >>> > -- Owen >>> > > >
