maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Release Maven 3.1.1
Date Sun, 22 Sep 2013 01:16:24 GMT
On 21 September 2013 23:09, Jason van Zyl <jason@tesla.io> wrote:
>
> On Sep 21, 2013, at 2:51 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 21 September 2013 22:28, Jason van Zyl <jason@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 <sebbaz@gmail.com> wrote:
>>>
>>>> On 17 September 2013 16:39, Jason van Zyl <jason@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message