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: >>> http://hudson.zones.apache.org/hudson/job/Hadoop-20-Build/67/console >> >> 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 > automake-1.9. > >>> 3) It would be nice if the tarball had libhdfs included in c++/lib >> >> It does have the .so for libhdfs. >> >> hadoop-0.20.2/c++/Linux-i386-32/lib/libhdfs.so >> >> 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 >> it. > > 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. > > Thanks > -Todd >
