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.
Arun
On Oct 21, 2010, at 5:51 PM, Eli Collins wrote:
On Thu, Oct 21, 2010 at 5:31 PM, Arun C Murthy <a...@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 <jho...@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
