On Sep 21, 2013, at 2:51 PM, sebb <[email protected]> wrote: > On 21 September 2013 22:28, Jason van Zyl <[email protected]> wrote: >> You will now be infamous :-) >> >> https://github.com/jvanzyl/sebbalizer >> >> If you don't like the name, happy to change it. I thought it was appropriate >> and meant as a compliment for being thorough. > > Thanks, but no thanks. > Sorry, but I don't like the association. >
No problem. https://github.com/jvanzyl/source-release-validator >> With a given staging URL, groupId, artifact, and version it will retrieve >> the source archive, and binary archive and the corresponding SHA1s and >> validates the SHA1s are right. It unpacks both the archives, digs into the >> binary archive to find the maven-core JAR to retrieve the build.properties >> which contains the SHA1 of the release revision from which the source >> archive was made. A git clone is performed and moved to the release >> revision. A check is performed to ensure that each file in the source >> archive is present in the release revision and that the SHA1 of the each >> file in the source archive matches the SHA1 of the file from the >> corresponding release revision. >> >> So for this release using the Sebbalizer I only found the DEPENDENCIES file >> to not exist in the release revision, every other file I consider valid and >> verified. I believe that for this release no errant files slipped in and >> it's good. >> >> People should review the code. I spent an hour on this by yanking a bunch of >> stuff together so it might very well have errors. I have one hardcoded url >> for the Git repository but I'll pull that out of the POM and then hopefully >> it can be used generally to validate source archives for releases. > > The general procedure seems fine, but the SCM coordinates still need > to be in the release vote in order to tie everything together for the > release vote, and for the historical record. > > Rather than pick out the details from the maven-core jar, the > information should be taken from the release vote e-mail. No, I think an automated way is better. As part of the release the release revision should be made available for use in the email. > That can then be used to ensure that the artifacts match the release > vote, and that the sources match the SCM tag. > The build.properties entry should be checked to ensure it is the same > as the value from the release vote mail. I want to go in the direction of automation and to generate this as part of the release so it will contain the revision. Going from a manually generated email is not a good solution. I can see the need for a secondary reference but I'm going to fully automate it. If I turn this tool into a Nexus Plugin I can potentially just generate the email. At any rate, I understand your concern to make sure there are no errant files and I believe this tool addresses those concerns. I think at this point with this it's not really necessary to put the release revision in the email template but that's for the PMC to decide. I'll continue to use the official template but I will also run this tool as part of the core releases. > >> On Sep 20, 2013, at 5:40 PM, sebb <[email protected]> wrote: >> >>> On 17 September 2013 16:39, Jason van Zyl <[email protected]> wrote: >>>> Hi, >>>> >>>> Maven Core ITs are good, and the license/notice issue has been resolved so >>>> I'm rolling 3.1.1 again. >>>> >>>> Here is a link to Jira with 6 issues resolved: >>>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18968 >>>> >>>> Staging repo: >>>> https://repository.apache.org/content/repositories/maven-065/ >>>> >>>> The distributable binaries and sources for testing can be found here: >>>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ >>>> >>>> Specifically the zip, tarball, and source archives can be found here: >>>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip >>>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz >>>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip >>>> https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz >>>> >>>> Source release checksum(s): >>>> apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d >>> >>> The full scm coordinates are needed. >>> The pom includes the git URL and tag, but that is not immutable. >>> Exactly the same tag was used for the previous vote. >>> >>> To identify the source archive uniquely, additional info such as a >>> hash is needed, so the hash is now included in the vote e-mail. >>> The same applies to the SCM tag. >>> >>>> Staging site: >>>> http://people.apache.org/~jvanzyl/maven-3.1.1/ >>>> >>>> Vote open for 72 hours. >>>> >>>> [ ] +1 >>>> [ ] +0 >>>> [ ] -1 >>>> >>>> Thanks, >>>> >>>> The Maven Team >>>> Thanks, >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
