Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of todd@cloudera.com designates
 209.85.210.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <FD5BC1D3-881A-4D45-BA2C-C6084C884418@apache.org>
References: <FBD8F805-4345-451E-AEA3-F19A2545C387@mac.com>
 <FD5BC1D3-881A-4D45-BA2C-C6084C884418@apache.org>
From: Todd Lipcon <todd@cloudera.com>
Date: Mon, 31 Jan 2011 15:23:10 -0800
Message-ID: <AANLkTikYHbb935h5Qo+YbsYyrAYPSYYoyjrL5APy_unC@mail.gmail.com>
Subject: Re: [DISCUSS] Move common, hdfs, mapreduce contrib components to
 apache-extras.org or elsewhere
To: general@hadoop.apache.org
Content-Type: multipart/alternative; boundary=90e6ba4fc5142bc6e4049b2cb420

--90e6ba4fc5142bc6e4049b2cb420
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 30, 2011 at 11:19 PM, Owen O'Malley <omalley@apache.org> wrote:

>
> Also note that pushing code out of Hadoop has a high cost. There are at
> least 3 forks of the hadoop-gpl-compression code. That creates a lot of
> confusion for the users. A lot of users never go to the work to figure out
> which fork and branch of hadoop-gpl-compression work with the version of
> Hadoop they installed.
>
>
Indeed it creates confusion, but in my opinion it has been very successful
modulo that confusion.

In particular, Kevin and I (who each have a repo on github but basically
co-maintain a branch) have done about 8 bugfix releases of LZO in the last
year. The ability to take a bug and turn it around into a release within a
few days has been very beneficial to the users. If it were part of core
Hadoop, people would be forced to live with these blocker bugs for months at
a time between dot releases.

IMO the more we can take non-core components and move them to separate
release timelines, the better. Yes, it is harder for users, but it also is
easier for them when they hit a bug - they don't have to wait months for a
wholesale upgrade which might contain hundreds of other changes to core
components. I think this will also help the situation where people have set
up shop on branches -- a lot of the value of these branches comes from the
frequency of backports and bugfixes to "non-core" components. If the
non-core stuff were on a faster timeline upstream, we could maintain core
stability while also offering people the latest and greatest libraries,
tools, codecs, etc.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

--90e6ba4fc5142bc6e4049b2cb420--