Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: error (nike.apache.org: local policy)
Date: Wed, 15 May 2013 16:17:37 -0700
From: Konstantin Boudnik <cos@apache.org>
To: common-dev@hadoop.apache.org
Subject: Re: [VOTE] - Release 2.0.5-beta
Message-ID: <20130515231737.GA27292@linspire.com>
References: <48A037BF-5EE8-44EA-BE27-0BBB46DA0B5B@hortonworks.com>
 <CA+ULb+uwrzG7QBiVep1A-K8iL1fhTKSG9-c3O7Wmezh2qi6ieQ@mail.gmail.com>
 <548593E8-2791-4975-9710-D5D1EC51C516@apache.org>
 <CA+ULb+s5yac-D9LKmc9psCMDA8CqDutNVfvYGAOv8kG27ACU3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
 <CA+ULb+s5yac-D9LKmc9psCMDA8CqDutNVfvYGAOv8kG27ACU3w@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)

Indeed. I think the root of the issue is deeper. ASF software practices are
great to deal with isolated, relatively contained projects like httpd,
libreoffice, trac, etc. However, Hadoop based stack - essentially, software
aimed at enterprises with bigger scale operations - is a different animal,
that requires balancing of a huge number of moving parts and an unbroken
flow of feedback up the stream. Anyone who have delivered any enterprise
grade software system knows perfectly well how hard is that.

However, in the environment where a release pushed out in the rush
(essentially causing DOA issues downstream), these are got fixed in consequent
releases.  That ironically is likely to contain some other DOAs because an
integration testing - and I mean real world integration system testing - is
done by this small project, that is treated like a toy for adolescent kids.
And there's no other real integration testing happening OPENLY on the full
stack. Despite numerous claims, that is.

Software comes with bugs - this is a somewhat expected phenomena. However, bug
fixes shouldn't be mixed with new features, increasing entropy in the system.
In other words, the development process should fan-in. A process with multiple
consequent stable releases helps to achieve it; and compatibility issues would
be addressed by working on the next major release.

The model above leaves downstream with a choice of sticking to the 3.x or switching
to 4.x and so on. Where's having permanent alpha tag is a convenient way to control
software project that effectively became a vendor-controlled effort.

And yes - this leads to fragmentation, makes no mistakes about it. Because no
one can sit on the hands for a year and wait until a usable release with all
great features will come about: lot of organizations just silently forking away
to make their own environment suitable for production or sale; some of them
might sporadically contribute something back. And of course - this is not the
aim of Apache project to produce commercial grade platform.

Cos

On Wed, May 15, 2013 at 02:54PM, Roman Shaposhnik wrote:
> On Wed, May 15, 2013 at 2:14 PM, Vinod Kumar Vavilapalli
> <vinodkv@hortonworks.com> wrote:
> > Please list down all the issues that BigTop ran into *because of* new features.
> 
> Whether the bug is *because of* new feature or not is a red herring
> for my argument. Please lets drop this distinction. I never used it.
> 
> > 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.
> 
> This is not my argument at all. I apologize if somehow I failed to
> communicate it, but here's what my argument boils down to:
> given *my* experience with Hadoop 2.0.x series and Bigtop
> release every time I try a different release of Hadoop 2.0.x
> I run into issues that scare me. They scare me because
> they are so basic yet they make component like Sqoop
> and Oozie (and I believe Giraph on one occasion)
> pretty much DOA for YARN-base mapreduce implementation.
> 
> In my mind, what that translates into is the fact that nobody
> did *any* real testing of a particular downstream component
> running on a given Hadoop 2.0.x release. Like I said --
> the issues so far make the components in question DOA.

> Effectively the onion of issues remain unpeeled, so to speak.
> 
> What I'm asking on this thread (and somehow nobody is willing
> to give me a straight answer) is whether the Hadoop community
> is willing to invest in peeling this onion of issues somewhat more
> before declaring Hadoop 2.0.5 a beta release.
> 
> Once again it is a binary question -- please give me an answer
> of yes or no.
> 
> > I am not arguing that new features *may* destabilize the branch, but you've repeatedly stated this as if that were a fact.
> 
> Your list of issues is pretty complete (give or take a few that I didn't file
> but Cos and others did). And I'd be the first one to agree that
> it is not a large list of issues. What scares me is not its size,
> but the fact how basic they are and how the block the *rest*
> of the testing completely.
> 
> To be extra clear -- what scares me about something like
> MAPREDUCE-5240 is not whether it came as a result of
> a merge or was sitting there since day one. What scares
> me is that we've identified it last week and yet Sqoop 2 is
> DOA in its presense.
> 
> How many more issues like that one (regardless of how
> they originated) are in branch-2? Wouldn't we want to
> know before declaring Hadoop 2.0.5 beta?
> 
> Now, knowing would require work -- that's what my
> argument is all about.
> 
> 
> Thanks,
> Roman.