hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: bringing the codebases back in line
Date Fri, 22 Oct 2010 00:51:45 GMT
On Thu, Oct 21, 2010 at 5:31 PM, Arun C Murthy <acm@yahoo-inc.com> wrote:
> On Oct 21, 2010, at 5:17 PM, Eli Collins wrote:
>> On Thu, Oct 21, 2010 at 3:30 PM, Jakob Homan <jhoman@yahoo-inc.com> wrote:
>>> If the patch was just checking 1:1 Jira to patch, it would certainly not
>>> work.  We were uploading multiple patches to the same JIRA to avoid
>>> opening
>>> extraneous issues before generating patches for trunk. Venerable old
>>> HDFS-1150, for instance, went through about different patches applied to
>>> Y!'s branch before the final version.
>> That's what I meant by saying "a fair number of those may have been
>> included in trunk but under a different jira".  There seemed to be a
>> number of patches that are not in trunk under any jira (eg MR-1088,
>> MR-1100 where the jira is still open).  We need to go through the
>> patches in YDH and CDH and get them reviewed and checked in.
> It would be great to get HADOOP-6255, the functionality for creating RPMs,
> from CDH to Apache Hadoop.

There are some challenges in contributing packaging up stream:
- Packaging is typically versioned independently from the project code
(we share packaging code across project major versions). This is why
most projects have a separate repository for the packaging, and the
packaging is done by a distribution.
- The packaging source shares code across the 10 or so components,
which is useful since we continuously make the packaging more
consistent, so hosting the code on any single project repository
doesn't fit well.
- The packaging is Linux specific, we've gotten push back when trying
to contribute modifications upstream with Linuxisms since Apache
supports non-Linux platforms (namely Solaris).

All of our packaging is Apache licensed (and we publish source RPMs)
so there's no issue from that perspective.  But this is a digression
from the subject at hand so we should probably table for a separate


View raw message