well, lets see what others say. we don't want to ship stuff with serious regression to hdfs.
I will highlight that I am completely fed up with doing this release and really want to get it out the way -for which I depend on support from as many other developers as possible. Erik, right now what you can help by doing is test all the rest of the release knowing that this issue exists and seeing if you can identify anything else. That way this update will be the sole blocker and we can get through that next RC with nothing else surfacing. I had noticed that the arm64 release somehow missed out the native binaries and was going to investigate that but didn't consider that a blocker… I was just going to cut that artefact and, post Darcy, create a new arm64 release using all the jars of the x86 build but replacing the x86 native libs with the arm versions. This helps ensure that the JAR files in the wild all match, which strikes me as a good thing. Can I also encourage people in the HFS team to put their hand up and volunteer for leading the next release, with a goal of getting something out later this year. On Thu, 2 Mar 2023 at 00:27, Erik Krogen <xkro...@apache.org> wrote: > Hi folks, apologies for being late to the release conversation, but I think > we need to get HDFS-16923 > <https://issues.apache.org/jira/browse/HDFS-16923> into > 3.3.5. HDFS-16732 <https://issues.apache.org/jira/browse/HDFS-16732>, > which > also went into 3.3.5, introduced an issue whereby Observer NameNodes will > throw NPE upon any getListing call on a directory that doesn't exist. It > will make Observer NN pretty much unusable in 3.3.5. Zander put up a patch > for this and it has been merged to trunk/branch-3.3 as of a few minutes > ago. I'd like to see about merging to branch-3.3.5 as well. > > Thanks for the consideration and sorry for not bringing this up in RC1 or > earlier. > > On Mon, Feb 27, 2023 at 9:59 AM Steve Loughran <ste...@cloudera.com.invalid > > > wrote: > > > Mukund and I have put together a release candidate (RC2) for Hadoop > 3.3.5. > > > > We need anyone who can to verify the source and binary artifacts, > > including those JARs staged on maven, the site documentation and the > arm64 > > tar file. > > > > The RC is available at: > > https://dist.apache.org/repos/dist/dev/hadoop/hadoop-3.3.5-RC2/ > > > > The git tag is release-3.3.5-RC2, commit 72f8c2a4888 > > > > The maven artifacts are staged at > > https://repository.apache.org/content/repositories/orgapachehadoop-1369/ > > > > You can find my public key at: > > https://dist.apache.org/repos/dist/release/hadoop/common/KEYS > > > > Change log > > > https://dist.apache.org/repos/dist/dev/hadoop/hadoop-3.3.5-RC2/CHANGELOG.md > > > > Release notes > > > > > https://dist.apache.org/repos/dist/dev/hadoop/hadoop-3.3.5-RC2/RELEASENOTES.md > > > > This is off branch-3.3 and is the first big release since 3.3.2. > > > > As to what changed since the RC1 attempt last week > > > > > > 1. Version fixup in JIRA (credit due to Takanobu Asanuma there) > > 2. HADOOP-18470. Remove HDFS RBF text in the 3.3.5 index.md file > > 3. Revert "HADOOP-18590. Publish SBOM artifacts (#5281)" (creating > build > > issues in maven 3.9.0) > > 4. HADOOP-18641. Cloud connector dependency and LICENSE fixup. (#5429) > > > > > > Note, because the arm64 binaries are built separately on a different > > platform and JVM, their jar files may not match those of the x86 > > release -and therefore the maven artifacts. I don't think this is > > an issue (the ASF actually releases source tarballs, the binaries are > > there for help only, though with the maven repo that's a bit blurred). > > > > The only way to be consistent would actually untar the x86.tar.gz, > > overwrite its binaries with the arm stuff, retar, sign and push out > > for the vote. Even automating that would be risky. > > > > Please try the release and vote. The vote will run for 5 days. > > > > Steve and Mukund > > >
