hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Evans <ev...@yahoo-inc.com>
Subject Re: [VOTE] Release plan for Hadoop 2.0.5
Date Tue, 14 May 2013 18:32:39 GMT

I realize that my metaphor was not perfect none are.

I don't belive that .snapshots or any other features on the table are bad,
not well tested, or have design flaws. I am just stating that any time
thousands of lines of code are changed for any reason there will be bugs
no matter who wrote it and no matter who tested it.  We are all human and
we will all miss something. I simply want to reduce the time frame between
when code is written and when it is rolled out to be more fully tested. I
see API stabilization as a critical piece of this, and would like to help
the community get in a mindset where we are ready for rolling upgrades
when they do come. If the community thinks that snapshots or some other
feature should go in in the same time frame as API lockdown I am fine with
that. It just means that for me to go to production with that code will in
all likelihood take longer.

I apologize if "junkyard" or "dumping ground" has offended anyone. It was
not my intention to offend, I just wanted to describe what I have seen
happening where a change does not go into branch-2 for some reason
(possibly because of an incompatibility) and it will go into trunk.
Historically it would then sit with little more than unit tests to find
bugs.  I personally don't see any reason for a patch to go into trunk and
not branch-2 unless it breaks compatibility.  And if it breaks
compatibility why is it going into trunk? Is it really that difficult to
maintain compatibility and add new features at the same time? Then if
trunk and branch-2 are essentially identical why would we want to maintain
two copies of the same thing?  These are the questions that I struggle to
find an answer to, and are part of the reason why I am in favor of
Konstantin's proposal.  Although I do agree with you Chris that we need
more clarification in the roles involved with his release plan.


On 5/13/13 4:46 PM, "Chris Douglas" <cdouglas@apache.org> wrote:

>As much as I enjoy the Evel Knievel image, your argument is not
>finding traction for lack of a visceral metaphor. It's the lack of
>detail. We're not jumping buses, we're adding features to code, where
>it's possible to be specific. If you're uncomfortable with the design,
>implementation, or test plan of a feature, then share your
>reservations. Either someone can reassure you that your issue is
>covered by existing tests, they can add new tests, or- given enough
>evidence- we can agree that the feature needs more time to bake before
>being added to the beta. If you need extra time to do this, please
>insist. Given all that's been written, I literally can't believe that
>nobody has time to do this, and it would be a lot more productive.
>I share your concerns about trunk, abstractly. Currently, there's
>almost nothing there that isn't in branch-2 (which makes metaphors
>like "junkyard" and "dumping ground" sound a little hysterical,
>frankly). Once 2.x reaches beta, we should probably explore rolling
>new alpha releases to ensure it doesn't rot.
>On Sun, May 12, 2013 at 9:26 PM, Konstantin Shvachko
><shv.hadoop@gmail.com> wrote:
>> You keep twisting around the purpose of the vote and my position in it.
>> As I said before: http://s.apache.org/WBf
>> I am not against the features. And I am not blocking them.
>> I propose to release them in a different than yours order, addressing
>> features vs. stability tradeoff.
>It's possible we're confused. Your proposal sounds like Arun should RM
>a release with a particular profile. I apologize if I assumed more
>than you intended.
>> I don't know how to stop votes even if I wanted to.
>> As Apache members you should have more vote-stopping power than me if
>> think it is against ASF norms.
>The content of releases isn't a power struggle. You have all the tools
>and authority you need to create a release. Nobody has authority to
>block you, and frankly, nobody is trying. However, your technical
>input on the particular features would be most welcome. -C

View raw message