> How long do you > think will it take to unload things from trunk into branch-2 ? What's your > personal estimate?
This depends on the resources. I don't know how many people are in favour of streamlining. I know that some are interested in working on trunk only some on branch 1. Most people want to bring their code into branch 2. But don't know how many need stability. This is the purpose of the discussion. In the worst case we just leave everything go "as usual" and let fragmentation of the project to continue. Thanks, --Konstantin On Thu, Apr 25, 2013 at 8:44 AM, Roman Shaposhnik <r...@apache.org> wrote: > On Wed, Apr 24, 2013 at 8:17 PM, Konstantin Shvachko > <shv.had...@gmail.com> wrote: > > There was and is a number of discussions about Hadoop version > > compatibility, feature porting, stability. I think that many problems of > > Hadoop are the result of our flawed release processes and can be solved > by > > streamlining the releases. > > In my opinion this would be an extremely useful thing, especially > when it comes to us getting the maximum value of the downstream > projects providing feedback. Here's my favorite case in point: > > https://git-wip-us.apache.org/repos/asf?p=giraph.git;a=blob;f=pom.xml;h=6d2bdd1cf2399db119ab50e3dfb7a825b2930691;hb=HEAD > > Just count how many Hadoop 2.X'ish profiles there are. > > > This destabilizes the release canceling former efforts to fix bugs and > > provide working environment for the upstream projects. I mean stabilizing > > and adding features are mutually exclusive activities. This is in part > why > > Hadoop 2 stabilization effort is perpetual. > > I have a lot of sympathy for this (hence me starting that other thread). > > At this point, I completely agree with you that release early, release > often > would work well for Hadoop. I guess what I'm trying to say is that instead > of constantly trying to cram every last feature into branch-2 we should > pause > and decide where we draw the line and say that the new development > from now on will be known as hadoop 3.X (or something) and we're willing > to spend time to get to our *first* ever officially stable Hadoop 2.X. If > for > nothing else but to benefit the downstream developers. > > > My practical suggestions are: > > 1. Produce a series of feature releases to catch up branch-2 with trunk. > > We can prioritize features in general or let the release manager to > > decide which feature to pick up from trunk. > > Version numbering is also up for discussion. I would call them 2.x and > > reserve the minor numbers for subsequent stabilization bug-fix-releases. > > 2. Build new features in dev-branches until they are done. We do it now, > > but should enforce more. > > Here's a practical question: suppose we do the above. IOW, from now on > all features will be strictly confined to release branches. How long do you > think will it take to unload things from trunk into branch-2 ? What's your > personal estimate? > > > P.S. This is not to preempt discussion on stabilizing 2.0.5 started by > > Roman. I am just not sure why we call it stabilization and 2.0.5 and > betta, > > if incompatible and new features has already been committed to the > branch. > > BTW as an illustration to my observations above. > > I believe the two are related -- basically what I'm trying to address in > that > other thread is getting us to a point where we can at least agree on > the *criteria* for what beta means. Your proposal, in fact, layed out a few > things that seem to add up to that criteria (e.g. catching up with trunk). > > I really wish other would chime in, since without this type of > understanding > it is really difficult to make forward progress on the downstream front. > > Thanks, > Roman. >
