Hi Milind, I'd expect to see continued sustaining on the 20 branch until 23 is stable. Continued bug fixing beyond that if there is need / enthusiasm for such fixes would also seem reasonable. This has certainly been the expect behavior of other released software I've contributed to.
If we want to see apache hadoop widely adopted, it is critical that folks not only volunteer new features, but that someone continue to refine working releases. I see nothing but upside to this. If others want to only volunteer new code for trunk or want to work on other releases, that's ok by me. I don't believe this is a zero sum game. Any investment I put into 0.20 doesn't block you from putting work into 22 or 23. We're aligned in the goal of getting 23 and future trunk based releases out. Asking someone not to do sustaining will not cause them to work faster on other releases, it will just move work out of apache. I don't see how that benefits the community. If the sustaining work is badly done or does not add value, it can be voted down. Thanks, E14 On Aug 25, 2011, at 1:04 PM, <milind.bhandar...@emc.com> <milind.bhandar...@emc.com> wrote: > Thanks for the prompt response Eric. > > I have been traveling, and could reply to you immediately. > > How long do you estimate 0.23 (or 0.22) would take to stabilize ? Based on > the past experience of release 0.19, even if it was not deployed at 1000+ > node-scale, eventually, it did stabilize, and several small installations > did exist using that release. > > With that in mind, and knowing the typical deployment schedules at a large > installation, I would expect 0.23 to be stable for production workloads > next summer. Since that is still 10 months away, do you expect that > sustaining releases on the 0.20.2xx branch to continue until then ? > > - milind > > On 8/24/11 9:32 AM, "Eric Baldeschwieler" <eri...@hortonworks.com> wrote: > >> Hi Milind, >> >> I'm really happy to see 0.23 moving along. This seems like pretty clear >> evidence that 0.20.xxx is not going to be a new trunk. However, the time >> between cutting a new release and being able to run production >> applications on it can be very long. 0.23 and any alternative such as >> 0.22 will take a long time to get to the level of quality and stability >> that is in 0.20.xxx today. Trunk is looking very healthy to me. Having >> a good sustaining program on 0.20.xxx is intended to compliment mainline >> dev, not replace it. Describing fixing flush/sync as innovation seems >> like a stretch. The patch sets we are considering merging have been in >> use for more than a year. >> >> There is a large constituency that would like to see HBASE work well now. >> I'm hoping to see that happen on 0.20.xxx. I think this is the best >> place to invest effort. You are welcome to work with the community >> members investing in 0.20.xxx or on an alternative. There is room in the >> community for both efforts IMO. >> >> Thanks, >> >> E14 >> >> >> On Aug 24, 2011, at 12:05 AM, <milind.bhandar...@emc.com> wrote: >> >>>> At the same time, we certainly do not wish 0.20-security to be viewed >>>> as a "trunk"; it is important >>> that all patches go in trunk first, and only patches of manageable risk >>> and high value to production users, should go into >>> the sustaining releases. >>> >>> Matt, >>> >>> With all due respect, I have heard from "several of your associates", >>> about features for making hbase work with the 0.20.2xx. That sounds to >>> me that 0.20-security to be trunk. >>> >>> Can you clarify how that is going to work ? >>> >>> Basically, what are your criteria for "manageable risk and high value >>> to production users" ? >>> >>> In particular, I would like to know why the insistence on 0.20.2xx >>> being the default branch to check-in these "innovations", instead of >>> trunk. >>> >>> >>> * Milind >>> >>> --- >>> Milind Bhandarkar >>> Greenplum Labs, EMC >>> (Disclaimer: Opinions expressed in this email are those of the author, >>> and do not necessarily represent the views of any organization, past or >>> present, the author might be affiliated with.) >>> >> >> >
