-1 (non-binding)
I want to thank everyone on the thread for taking the time to present the
potential risks and benefits so clearly. There are valid arguments on
either side. My -1 vote is based on the fact that maintaining an extra
branch carries a high cost, and I do not see evidence that the potential
stability benefits would outweigh that cost.
Committers already have a heavy workload, and this plan would create a
scenario where committers need to manage merges not only between trunk and
branch-2, but also to a separate branch-2.0. This is in addition to
possible backports to branch-1 or 0.23.7.
I also do not see a definition of any specific development or testing
activity, beyond a vague sense of "bake time", that needs to happen inside
the new branch-2.1 for the new features to be considered stable. As others
on the thread have said, we all can work more effectively if stability
concerns are documented clearly as requirements in jiras, so that we have a
measurable goal and an entry point for engineers that want to volunteer on
stabilization.
As I understand it, the features under debate are secure short-circuit
reads, snapshots, and Windows compatibility. In all 3 cases, I've observed
multiple contributors, committers, and testers actively working towards the
goal of stability. I cannot think of any specific deficiencies that I need
to see addressed before I would deploy the code. (If I do think of
anything later, I'll document it in a jira, and I'm happy to help with
stabilization of any of those features.)
Of course, every new line of code carries risk. There will always be bugs.
In this case though, I think the proposal increases development workload
without significantly reducing the risk.
Chris Nauroth
Hortonworks
http://hortonworks.com/
On Mon, May 13, 2013 at 9:36 AM, Robert Evans wrote:
> If I have to get to the other end of 14 busses I can either do it Evel
> Knievel style and jump them all at once or I can walk from one end to the
> other, one step at a time. I personally would rather take many different
> small steps than try to take one giant flying leap and risk missing.
>
> Also I don't think anyone said that we are going to to a major release per
> feature. I thought the proposal was to do a 2.0 release before snapshots
> is merged in and a have snapshots go into 2.1. I don't really want to
> open up the version numbering discussion again but I want my quote to be
> interpreted the way I intended it to be. I don't see snapshots as a major
> change. I see it as a step. I just don't see a reason to keep two
> parallel lines branch-2 where we try hard to maintain compatibility, and
> trunk where is is a dumping ground that only makes it more difficult to
> move to in the future.
>
> --Bobby
>
> On 5/10/13 1:55 PM, "Arun C Murthy" wrote:
>
> >
> >On May 9, 2013, at 10:03 PM, Uma Maheswara Rao G wrote:
> >
> >> Adding new features really a great thing and surely each big feature
> >>can be included in one one major release as well.
> >
> >
> >Surely the one thing we have learnt over the last 4-5 years in this
> >project is that we cannot make too many major releases. Notice how long
> >hadoop-0.20/hadoop-1 lives; the same will happen with hadoop-2.x. Look at
> >Bobby's message on this thread on *-dev lists:
> >
> >>>> Up to this point we have almost successfully done this switch once,
> >>>>from 1.0 to 2.0. I have a hard time believing that we are going to do
> >>>>this again for another 5 years.
> >
> >Each major release is a *lot* of work and is, subsequently, an
> >opportunity where incompatibilities at various levels creep in - our
> >users are not well served by this.
> >
> >So, it's a fallacy that we can and should make major releases per
> >feature.
> >
> >Arun
> >
>
>