If we include symlinks, security and Avro in 0.21, then what's the feature set for 0.22? Do we have any big items planned?
Thanks, Tomer On Thu, Feb 18, 2010 at 6:12 PM, Todd Lipcon <[email protected]> wrote: > On Thu, Feb 18, 2010 at 6:08 PM, Konstantin Shvachko <[email protected]> > 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<[email protected]> > 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 > >>> > > > > > > -- Tomer Shiran Director of Product Management | MapR Technologies (www.mapr.com) | 650-804-8657
