The other thread or "vote" or whatever at least served the purpose in fresh surfacing of concerns. Talk of new features going in to a "beta" on a very short short timetable is concerning for anyone with experience working on large software projects. It's not a little ironic that this vote thread, done in response to sort out the other one predicated on stability concerns, begins with a laundry list of features and JIRAs to go in. I think it is usually the case that a beta release receives only bugfixes* over the alpha that proceeded it. This may just be a lack of consensus on what "beta" means.
Please set aside discussion on particular features or Hadoop bylaws or politics or debate club. I can't speak for all of downstream of course, but to the extent that I can I can say we don't care about that. The core ask, at least mine, is take a fresh look at reducing per-release disruptions to the rest of the entire ecosystem that has grown up around Hadoop. Any change made in Hadoop does not happen in isolation. On that other thread were good suggestions on more frequent releases, reducing the change scope per release, adopting merge windows, etc., all with the aim of allowing downstream the time to sort out integration issues. The other comment on this thread that suggests ASF governance structures being inadequate for negotiating changes in a large ecosystem might be on to something, but at the same time Apache BigTop may be an effective ASF-native answer to that. Time will tell. It seems the tone of discussions between BigTop and Hadoop in this thread are better than in the past. I will take further discussion on volunteering resources to the BigTop lists. * - I think this would include the great recent work in YARN on API stability and in MR on restoring some backwards compatibility with MR1, but perhaps these only meet my personal definition of bugfix, granted. On Thu, May 16, 2013 at 5:20 AM, Arun C Murthy <a...@hortonworks.com> wrote: > Great summary, thanks Vinod. > > On May 15, 2013, at 2:14 PM, Vinod Kumar Vavilapalli wrote: > > > > > Roman, I keep this same argument again and again. Should've refuted > earlier. > > > > Please list down all the issues that BigTop ran into *because of* new > features. You continue to argue that new features are destabilizing 2.0.*, > which I don't agree with at all. 2.0.3-alpha was the last time major > features got merged in, and we found blockers irrespective of those. > > > > MAPREDUCE-5240 specifically isn't due to any feature merge. This was a > bug. I'd say this is a long standing bug in 2.0.x. You sure this passed in > 2.0.3? Even so, this is mostly broken by another bug-fix and *not* because > of any feature. > > > > I quickly checked other bugs you reported in 2.0.x: > > - MAPREDUCE-5088 was caused by the fix for HADOOP-9299 which was again a > long standing issue in 2.0.x > > - MAPREDUCE-3728 is similar > > - MAPREDUCE-5117 is similar > > - MAPREDUCE-4219 was a security related feature request from you. > > - MAPREDUCE-3916 was because of new proxy-server added. > > > > I am not arguing that new features *may* destabilize the branch, but > you've repeatedly stated this as if that were a fact. > > > > Really appreciate the testing done by BigTop, but please don't distort > the facts. > > > > Thanks, > > +Vinod > > > > > > On May 15, 2013, at 1:29 PM, Roman Shaposhnik wrote: > > > >> Please tell me if my expectations are incorrect, but to me the -beta > would > >> signify it being a 'safe' target for the downstream components. We're > still > >> finding *very* basic and *very* disruptive issues (MAPREDUCE-5240 is > >> a good example) that essentially mean DOA for downstream that depends > >> on this functionality. > >> > >> Are we comfortable with delivering 2.0.5-beta and later on starting > >> to discover things like MAPREDUCE-5240 more or less accidentally? > > > > -- > Arun C. Murthy > Hortonworks Inc. > http://hortonworks.com/ > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
