hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@yahoo-inc.com>
Subject Re: bringing the codebases back in line
Date Fri, 22 Oct 2010 00:57:23 GMT
I was merely pointing out, given the number of interested parties on  
that jira, that having Hadoop RPMs for Linux is very desirable.

We could have a technical discussion on the ways to go about doing  
RPMs, debs etc., but it is clear that there is a need for something  
more than tgz releases, even if they are Linux specific. This is  
particularly true given Linux specific components such as  
LinuxTaskController, jsvc for security etc.


On Oct 21, 2010, at 5:51 PM, Eli Collins wrote:

> 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
> discussion.
> Thanks,
> Eli

View raw message