Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> [VOTE] Release plan for Hadoop 2.0.5


Copy link to this message
-
Re: [VOTE] Release plan for Hadoop 2.0.5
> 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.

Apologies accepted.
It is really hard to explain things to anybody who doesn't want to hear you.

> You have all the tools
> and authority you need to create a release. Nobody has authority to
> block you,

Wouldn't it be good to come to common ground and work on a single community
release.

> your technical input on the particular features would be most welcome.

Again as I said before it is not about technical issues, on which I spent
as much time as I could - wish I had more.
Repeating myself here:
I am not challenging any features, the implementations, or the developers.
Adding a 500 KB patch invalidates prio testing solely because it is a big
change that needs testing not only by itself but with upstream applications.
With 2.0.3 , 2.0.4 tested thoroughly and widely in many organizations and
several distributions it seems like a perfect base for the stable release.

What work for me may not work for you. What works at Twitter may not work
at Intel. What is compatible with HBase may be incompatible for Impala.
What runs on Oracle Java may break on IBM's. What passes on Centos 6.1 may
fail on Suse 11. What is optimal for 100 node cluster stalls at Yahoo
scale.
There is too many dimensions some of which we don't even know about.
Stability doesn't come by declaration or tagging. It rather happens where a
critical mass accumulates, sometimes unpredictably. We just need to
recognize the moment.

People indeed spent a lot of time expressing themselves. Means to me it is
important to them. It would be sad to see the effort wasted.

Thanks,
--Konstantin

On Mon, May 13, 2013 at 2:46 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
>
> Bobby-
>
> 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
> <[EMAIL PROTECTED]> 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
you
> > 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB