See comments inline. On 11/22/2011 03:11 PM, Roman Shaposhnik wrote: > Pulling this into a separate thread: > > First of all, I wanted to reiterate that the proposal was > from a stand point of me volunteering for a RM role for > Bigtop 0.3.0. It was intended to reflect my personal confidence > and the consensus that we've built in other thread (obviously > given -1, the consensus wasn't really there :-(). > >> 1/ Latest openSUSE and Fedora are respectively 12.1 and 16 > You're absolutely correct. I specifically didn't say "latest" versions, > but stuck with the current ones. Is there any reason you feel > so strongly about bumping the versions of these OSes?
I do all my work on latest Fedora/Mageia. So I will not test Fedora 15 at all. So you get support for Fedora 16 for free. >> 2/ We should move trunk to Apache Hadoop 0.23 before January. By then a >> few projects should have fixed their compatibility issue with Apache >> Hadoop enabling us to push for a release with more than just Hadoop 0.23. > I disagree strongly. By doing that we would be making any future release > of Bigtop hostage of all the components that we have to support on top of > .23. I will expected quite a few of them not to have official releases > compatible > with .23 till at least mid 2012. Does it mean that we don't do release of > Bigtop > between now and (worst case scenario) Mid 2012? > > From my point of view -- that would be mostly unfortunate. Hence my suggestion to have a stable branch for releases based on the 0.20.20X generation and having trunk based on the next gen Hadoop. The stable branch being there for people wishing to use a stable distribution and the coming releases of Bigtop to be used as a solid base for helping projects improving their compatibility with Hadoop 0.23. This will also have the added benefit on helping putting Hadoop 0.23 in more people's hands and improve Bigtop's Hadoop 23 support. I wouldn't mind at all having a release of Bigtop with just Hadoop 0.23 + HBase + other compatible projects, and reactivating these projects one by one as they get compatible with Hadoop 0.23. So we don't have to wait mid 2012 to have a release of Bigtop based on Hadoop 0.23. But either way, we cannot wait for +10 projects to all sync up to get Bigtop moving. >> 3/ I thought we would base releases based on a ~ quaterly schedule and >> not features. >> Regarding 2/, we should probably do a last release before moving to >> Hadoop 0.23.X (probably X =1 or 2) and use that branch for future >> versions of Hadoop 0.20.20X as stable branch. > That is, essentially, why I started the vote. I strongly believe that having > a release in mid-end Jan 2012 with so much new stuff in it will be > very beneficial to the Bigtop community. We will be putting long anticipated > versions of components (such as HBase 0.92 and Zookeeper 3.4) into > the hands of the users and that's what Bigtop is meant to do. > > Yes, I would like to stick to the purely quarterly release schedule myself, > but having a 20.20X based release end of Feb is going to feel odd at best. > > So the choice is a simple one -- have the next release (I don't care what > version we give to it as long as it is monotonically increasing from 0.2.0) > of Bigtop 2 months from now (and have it based on 0.20.200X) or have > a release of Bigtop (worst case scenario) in 6 months. See my reply above. I disagree with the choice you are presenting. This is about having trunk as stable hadoop 0.20.20X and a unreleased hadoop 0.23 branch no one will use, versus a branch for stable hadoop 0.20.20X and trunk for future releases of Hadoop 0.23. I am rather in favour of "release early and often" and therefore the later option :) > Thanks, > Roman.
