On Wed, May 15, 2013 at 10:52PM, Suresh Srinivas wrote: > > Assuming that you are talking about HDFS features when you say > > > > "features going into a beta on a very short short timetable" and > > > "laundry list" etc, > > > > > > > No, that would not be a correct assumption. > > > > So these features are not something that are impulsively developed > > > and irresponsibly pushed to a release. They have gone through > > > considerable testing and have been developed over a long time. > > > > > > > There is no need to reframe my comment in combative terms and read in > > insults that are not there. > > > > No insult taken. But I want to make a case that feature are not proposed > lightly and due diligence both during development and testing are done. > > > > > As I read Arun's mail the plan is to integrate several feature branches > > into branch-2. That would of course result in brand new never before tested > > code. I do not believe that should have the label "alpha". This is just my > > personal opinion. "Shit happens when commits happen." - You know this as > > well as I. That does not mean I am here to attack or insult you by pointing > > that out and suggesting more measured alternatives. > > > > There is little to gain in engaging in debate club. If you are not > > interested in hearing these opinions, that is fine, I have received that > > message already, nothing further need be said. > > > Andy, I value your feedback. I am only trying to allay the concerns by > sharing my perspective.
What I am seeing times and again in these endless discussion threads is this:
a) "downstream or bigtop: we are seeing a bunch of integration issues with
every new feature introduced/something even a commit made"
b) "feature developers: no-no, these features are developed for a long time,
tests are ran, no need to be concerned"
The same pattern is repeated times and again. The only conclusion that I can
make out of it, is that either the meaning of "integration testing" is
different for a) and b) or that a) and b) are using very different validation
mechanisms.
Which one is that? I am puzzled.
Bugs are quite expected - Andrew put it very eloquently, actually. But you
only can deal with them effectively if the flow of changes is controlled, e.g.
via smaller and focused releases. The development process has to be
converging, and not fanning-out. Case in point? Sure. 2.0.3-alpha had to be
followed by 2.0.4-alpha release (officially called bugfix release); it - in
turn - requires 2.0.4.1-alpha to make it suitable for other downstream
components. So, it took 2 releases to simply fix issues caused by a bunch of
bugfixes and no major new features being committed into 2.0.3-alpha. These are
just cold facts - not attacking any ones' ego here.
Cos
signature.asc
Description: Digital signature
