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 > <vino...@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.
