Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MailScanner-NULL-Check: 1269869523.08496@uTyJjD+XQQ8lvCj7gQ7W/g
Message-ID: <4BA77159.4090902@apache.org>
Date: Mon, 22 Mar 2010 13:32:09 +0000
From: Steve Loughran <stevel@apache.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100228)
MIME-Version: 1.0
To: general@hadoop.apache.org
Subject: Re: 0.21 Release
References: <656B2F92-03D7-46AB-B49B-C8CBFE2F8BA9@speakeasy.net>
 <7c962aed1003191151g18b6efc3m5b89385ade5cc29f@mail.gmail.com>
In-Reply-To: <7c962aed1003191151g18b6efc3m5b89385ade5cc29f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stack wrote:
> On Fri, Mar 19, 2010 at 9:43 AM, Jeremy Davis <jerdavis@speakeasy.net> wrote:
>> ...and I also saw release 0.21 as is with stack as the release manager. Was
>> there a final decision on this off list?
>>
> 
> On the above, I was toying with the idea of being release manager for
> releasing as hadoop 0.21.0 what is in current 0.21 hadoop branch but I
> subsequently decided against it after chatting with folks and figuring
> that the only group that seemed interested in driving a release of the
> hadoop 0.21 branch was the hbase crew.  If I were to guess, an hadoop
> vouched for by a couple of hbasers with their spotty hdfs and
> mapreduce knowledge probably wouldn't have the penetration of a
> release backed by, say, a Yahoo.  No one would trust their data to
> such a release.  If no data in hadoop 0.21 clusters, hbase wouldn't
> have anything to run against.  So I let it go and figured time could
> be spent better elsewhere; e.g. helping test the set of patches that
> could get us a sync/flush/append on a patched hadoop 0.20 (hdfs-200,
> etc.).
> 
> Sorry, I should have added a note to cited thread that I'd wandered...
> 
> St.Ack

I'm not going to volunteer to help with this as my changes are still not 
in 0.22, which is what I'm trying to target, but I'd certainly approve 
of cutting a release if only because
  - it ensures the release process itself works well. When we were doing 
releases every fortnight at work, you make sure everything is automated 
that can be automated.
  - with 0.22 adding security, I expect its deployment will be traumatic 
and take longer to roll out than anyone expects
  - there are lots of improvements in 0.21; getting into a world of 
backports is complicated. Better to keep momentum up.

The big concern has to be the filesystem. Who out there is willing/able 
to test 0.21-based filesystems, and what size clusters do they have?

-steve