hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <mfo...@hortonworks.com>
Subject Re: Community Process for 0.20.205 Sustaining Release
Date Wed, 24 Aug 2011 18:09:22 GMT
Hi Milind,
Thanks for your response.  If you'll forgive me for reiterating statements
that you've probably heard before, I'll try to
concisely state why the community might consider accepting changes for HBase
compatibility into 0.20.2xx.

It is my understanding that HBase works correctly in trunk (soon to be
branched as v23), with both security and append.
Therefore, making changes in 0.20.2xx to enable HBase to work there, would
not constitute an innovation or new feature
that isn't already in trunk.  Nor is it a new feature relative to 0.20,
since HBase currently works with (and is recommended for
installation with) 0.20-append, which was branched from 0.20.2, and
developed quite a while back.

There are production users of HBase that want to stay with 0.20, since later
releases with security have not yet reached
stability, but also want the security features of 0.20.2xx.  To meet their
needs, it seems reasonable to consider joining
HBase-compatibility features like those of 0.20-append with the
0.20-security branch.  That doesn't seem to be using
0.20-security as a "trunk", although the semantics of that word can of
course be argued.  And it seems to meet the
criterion of high value to production users.

It still has to be asked whether the changes meet the criterion of
manageable risk.  That definitely should be evaluated
after we see the proposed patches.

Does that address your questions?

Regarding the definition of "manageable risk and high value to production
users", I think the community has to decide
that on a case-by-case basis.  Certainly the production users are capable
of expressing their opinions for what they want.
Developers should (and no doubt will) also do so, in the Jiras and in email

But the most important suggestion in my previous email is that we provide a
forum for such discussions PRE-release,
"up front", rather than only during the release vote.


On Wed, Aug 24, 2011 at 12:05 AM, <Milind.Bhandarkar@emc.com> wrote:

> > At the same time, we certainly do not wish 0.20-security to be viewed as
> a "trunk"; it is important
> that all patches go in trunk first, and only patches of manageable risk and
> high value to production users, should go into
> the sustaining releases.
> Matt,
> With all due respect, I have heard from "several of your associates", about
> features for making hbase work with the 0.20.2xx. That sounds to me that
> 0.20-security to be trunk.
> Can you clarify how that is going to work ?
> Basically, what are your criteria for "manageable risk and high value to
> production users" ?
> In particular, I would like to know why the insistence on 0.20.2xx being
> the default branch to check-in these "innovations", instead of trunk.
>  *   Milind
> ---
> Milind Bhandarkar
> Greenplum Labs, EMC
> (Disclaimer: Opinions expressed in this email are those of the author, and
> do not necessarily represent the views of any organization, past or present,
> the author might be affiliated with.)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message