On 21 September 2013 23:09, Jason van Zyl <ja...@tesla.io> wrote: > > On Sep 21, 2013, at 2:51 PM, sebb <seb...@gmail.com> wrote: > >> On 21 September 2013 22:28, Jason van Zyl <ja...@tesla.io> 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
Thanks. >>> 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. It would still be automated. However the source data would come form the vote e-mail, which makes more sense to me. > As part of the release the release revision should be made available for use > in the email. I agree the release revision needs to be part of the e-mail; that is what I have been requesting all along. >> 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. +1 > Going from a manually generated email is not a good solution. I disagree; so long as the e-mail has a reasonably standard format, it should be easy enough to extract the data to to the checks. > I can see the need for a secondary reference but I'm going to fully automate > it. It's not a secondary reference. The vote e-mail is the primary reference. > If I turn this tool into a Nexus Plugin I can potentially just generate the > email. Again, I think that's backwards. The point is that any reviewer needs to be able to check the release. > At any rate, I understand your concern to make sure there are no errant files > and I believe this tool addresses those concerns. The problem is that without the SCM coordinates it's not possible for a reviewer to independently check the source contents. They may use your tool to do so, or they may use other methods; that is up to them. The point is that it must be possible to independently audit the source release. The vote e-mail chain is the official means by which releases are sanctioned. Therefore the vote e-mail needs to contain all the required information; it should not be necessary for the reviewer to go digging for the information. > 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 <seb...@gmail.com> wrote: >>> >>>> On 17 September 2013 16:39, Jason van Zyl <ja...@tesla.io> 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: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> >>> >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
