-Re: [VOTE] Release candidate for Hadoop 0.20.2
Chris Douglas 2010-02-12, 10:41
I committed HADOOP-5611 to 0.20 and MAPREDUCE-1251 to 0.21 and 0.20. I
am suggesting slight modifications to HADOOP-5612 but think it should
also be included (btw: the original patch was *not* licensed to the
ASF; if the author re-posts the patch with permission granted, would
that be sufficient?). A backport of MAPREDUCE-623 should also be
applied to 0.20; the javac warnings are pretty ugly, if benign.
None of these issues are critical, though; if no other issues are
found with this RC, I'm +1 on releasing it, but would like to include
these if another candidate is rolled. -C
On Thu, Feb 11, 2010 at 9:20 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 11, 2010 at 9:00 AM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
>> On Feb 10, 2010, at 10:51 PM, Todd Lipcon wrote:
>>> I applied HADOOP-5612 to fix this, though I think creating a tarball
>>> after chmod 755ing the configure scripts would also be correct.
>> *Sigh* You can't blame a release for not containing one of your patches, if
>> you didn't ask for it to be applied to the relevant branch. If you want it
>> to be included in the next 0.20 release, reopen the jira and ask for it to
>> be applied back to branch-0.20.
> Yes, I should have asked at the time to put it in 20. I had newly
> started working on Hadoop when I did that patch and didn't know the
> proper JIRA protocol at the time. Will do so now. Like I said in my
> mail, I'm not trying to block a release. I'm just reporting the errors
> I ran into trying to use the release candidate - if the rest of the
> community or PMC thinks it's not worth rolling a new one, I'll leave
> it up to them.
> Regardless, it has nothing to do with whether it's "my patch" - I
> think it reflects poorly on the project when the releases fail to
> build on a common system configuration.
>>> These same problems are present as seen in the branch-20 Hudson build:
>> The problem on Hudson seems to be that automake 1.9 is not installed. That
>> seems like a different issue.
> automake should not be a build time requirement for released artifacts
> in pretty much any sane project. autotools "make dist" targets always
> include a configure script, which means automake was already run by
> the developer. After applying the patches mentioned above that fix
> missing header includes, I built just fine on my box that has no
>>> 3) It would be nice if the tarball had libhdfs included in c++/lib
>> It does have the .so for libhdfs.
>> I assume you were looking for the 64 bit version. Did someone get the 64 bit
>> libhdfs working? If so, we should update the HowToRelease twiki to include
> After applying the patches I mentioned, the ant command quoted above
> succeeded in building libhdfs just fine:
> build/c++/Linux-amd64-64/lib/libhdfs.so.0.0.0: ELF 64-bit LSB shared
> object, x86-64, version 1 (SYSV), dynamically linked, not stripped
> If others think these are blockers, I'm happy to roll a new candidate
> tarball later this week once they've been pushed into branch-20.
> Although I don't have a binding vote in the release process, I am
> pretty sure the ASF policies are fine with anyone rolling an rc and
> calling a vote. If no one else thinks these patches are worth stalling
> for, that's fine too.