Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of shv.hadoop@gmail.com
 designates 74.125.83.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=nRlDJsvU0oW2jkyZKEQpqDVZ77ydM+gaKGrJ42tqny4TLHM66qaB20G63vuxIwulCi
         rHo5Jc5kNh4OVaUgcensF9w1djEoQB4ytYB86PUBHppE39W1LWZQfsAJxLXT+xATE+b6
         WxjXP+U9X8CUgm1Z25oogGefs0yiIuvXMHrJA=
MIME-Version: 1.0
In-Reply-To: <BANLkTim0UJoc_r6VCE5dOjosFw=C79ppkw@mail.gmail.com>
References: <CA0BEEA9.1AA9A%sureshms@yahoo-inc.com>
	<CE461C76-D5B4-4C47-A96B-919F1FEF658E@apache.org>
	<5786C837-900C-4371-A3D2-568F1E2F8264@yahoo-inc.com>
	<BANLkTik-5mHTP++D_A_Q=G5qBM52mnCj3Q@mail.gmail.com>
	<BANLkTim0UJoc_r6VCE5dOjosFw=C79ppkw@mail.gmail.com>
Date: Thu, 2 Jun 2011 11:06:38 -0700
Message-ID: <BANLkTimirnAWcd2SrMvEAbHBptzo33nbDg@mail.gmail.com>
Subject: Re: Update on 0.22
From: Konstantin Shvachko <shv.hadoop@gmail.com>
To: general@hadoop.apache.org
Content-Type: multipart/alternative; boundary=000e0cd6a84099682f04a4be7fdc

--000e0cd6a84099682f04a4be7fdc
Content-Type: text/plain; charset=ISO-8859-1

I propose just to make them blockers before committing to attract attention
of the release manager and get his approval. Imho, even small changes, like
HDFS-1954 are blockers, because a vague UI message is bug and bugs are
blockers.
Thanks,
--Konstantin


On Thu, Jun 2, 2011 at 10:39 AM, Todd Lipcon <todd@cloudera.com> wrote:

> On Wed, Jun 1, 2011 at 11:32 PM, Konstantin Shvachko
> <shv.hadoop@gmail.com>wrote:
>
> > I can see them well.
> > I think Suresh's point is that non-blockers are going into 0.22.
> > Nigel, do you have full control over it?
> >
>
> Of course it's up to Nigel to decide, but here's my personal opinion:
>
> One of the reasons we had a lot of divergence (read: external
> branches/forks/whatever) off of 0.20 is that the commit rules on the branch
> were held pretty strictly. So, if you wanted a non-critical bug fix or a
> small improvement, the only option was to do such things on an external
> fork. 0.20 was branched in December '08 and not released until mid April
> '09. In 4 months a fair number of bug fixes and small improvements go in.
> 0.22 has been around even longer. If we were to keep it to *only* blockers,
> then again it would be a fairly useless release due to the number of
> non-blocker bugs.
>
> Clearly there's a balance and a judgment call when moving things back to a
> branch. But at this point I'd consider small improvements and pretty much
> any bug fix to be reasonable, so long as it doesn't involve major reworking
> of components. Nigel: if this assumption doesn't jive (ha ha, get it?) with
> what you're thinking, please let me know :)
>
> -Todd
>
>
> > On Wed, Jun 1, 2011 at 1:50 PM, Eric Baldeschwieler <
> eric14@yahoo-inc.com
> > >wrote:
> >
> > > makes sense to me, but it might be good to work to make these decisions
> > > visible so folks can understand what is happening.
> > >
> > > On Jun 1, 2011, at 1:46 PM, Owen O'Malley wrote:
> > >
> > > >
> > > > On Jun 1, 2011, at 1:27 PM, Suresh Srinivas wrote:
> > > >
> > > >> I see that there are several non blockers being promoted to 0.22
> from
> > > trunk.
> > > >> From my understanding, any non blocker change to 0.22 should be
> > approved
> > > by
> > > >> vote. Is this correct?
> > > >
> > > > No, the Release Manager has full control over what goes into a
> release.
> > > The PMC votes on it once there is a release candidate.
> > > >
> > > > -- Owen
> > >
> > >
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

--000e0cd6a84099682f04a4be7fdc--