On 2018/04/15 21:39:04, Christopher <ctubb...@apache.org> wrote: > On Sun, Apr 15, 2018 at 10:11 AM Sean Busbey <bus...@apache.org> wrote: > > > -1 on the RC vote > > > > I agree that in the staged maven repository we should stick to SHOULD > > guidance until such time that the maven tooling has a supported option to > > use correct checksums. (Have we verified that the relevant tooling at a > > minimum has a request in to add it?) > > > > > https://issues.apache.org/jira/browse/MNGSITE-328, and related issues track > this. >
Reading more on this it seems like there's also a problem on the Nexus side with hosting SHA256 / SHA512 checksums, so we're probably in for a long wait on that bit. > > > However, I can't verify that the source artifact or any other artifacts > > that we'll eventually place in dist.a.o/release has correct checksums that > > meet the current release distribution policy simply because we don't have > > the relevant bits posted here in the RC. > > > > > You can't verify the contents of what will eventually be there anyway... > anybody could copy things incorrectly. But, they *should* be what was in > the staging directory... so you can always do a byte-for-byte comparison to > the staging repo (which gets promoted to Maven Central) and verify the > checksum matches that. > Those are very different levels of effort. In one case I can see if the thing folks voted on is the thing that's hosted (or at least the thing I end up with when I download the thing that's hosted). the checksums are supposed to serve this purpose. > > > Why don't we go back to providing both a staged maven repo and an RC > > directory in the ASF dev part of dist.a.o[4]? Plenty of other projects use > > that area to stage RCs that have correct checksums. > > > > > "go back to" doesn't make sense here. To my knowledge, we've never done > this. While using this SVN dev area is somewhat common now, before we > started staging in Nexus consistently, the SVN dev area on dist was not > standard, and people staged tarballs in people.apache.org and elsewhere. > When a release vote passed, people would do a `mvn deploy` from the > unpacked source tarball or from the SVN tag (meaning the jars in the binary > tarball did not match what was in Maven Central, and possibly from a > slightly different source with no way to verify). Staging in Nexus solved > all of that. Furthermore, two staging areas causes additional concerns > (which one is canonical? What if some people only test one, but not the > other? What if SVN contents change because unlike a closed Nexus staging > repository, SVN directory contents are not immutable?). > I guess I misremembered us using the SVN dev area. In any case I'm not concerned with where we host the RC bits so long as I can vote on all the things that will eventually go in to dist.a.o's release area. Otherwise what good does checking that the checksums are correct do? All the rest of these concerns are implementation details. If you post one thing and say "this is the part that will go into the release area of dist.a.o" then _that_ one is the canonical one by definition. So long as folks say which one(s) of the staging areas they verified and we have coverage over both, then it hardly matters if some folks might not be checking all of them. SVN mutability has plenty of solutions, if we're really hung up on it. > I've thought about modifying our build.sh script to stage stuff in SVN to > help reduce human error... but it doesn't entirely address all those > concerns about two staging areas. Additionally, that's a new step being > added to the release process... and discussions about changing our release > process to do additional things like that fall outside the scope of this > release vote. We're voting on the release artifacts here, not voting on > revamping the release process. Let's not hold up a release because of wish > list items for the release process. > Again, to be clear, I don't care what the particulars of the release process are so long as they allow me to vote on the thing that ASF release policy says I'm supposed to vote on. Release votes are majority in any case. I'm pretty sure even if I vote -1 on every release for the rest of my life on this basis the rest of the PMC could ignore my concern if y'all wanted to. > Since it seems to be a problem for folks this time around... I've manually > staged the artifacts in: > https://dist.apache.org/repos/dist/dev/accumulo/1.9.0-rc1 > If you started a new VOTE thread that included these artifacts as those that would go into dist.a.o's release area, then I would evaluate the candidates without the need to -1 because I couldn't check the things we're planning to publish. As is, I think changing the contents of the RC mid-vote is ill advised mostly because it's confusing (e.g. how do we know folks who already voted are still on board if they don't respond?). We have several folks who already voted based on what's posted in Nexus. You're the RM for the vote. If you want to tally just based on those votes or if you want to cancel and start again, either is your prerogative.
