maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@tesla.io>
Subject Re: [VOTE] Release Maven 3.1.1
Date Sun, 22 Sep 2013 02:09:30 GMT
On Sep 21, 2013, at 6:16 PM, sebb <sebbaz@gmail.com> wrote:

> On 21 September 2013 23:09, Jason van Zyl <jason@tesla.io> wrote:
> 
> It would still be automated.
> However the source data would come form the vote e-mail, which makes
> more sense to me.
> 

If it were generated I would agree. Manually making an email is not automated or consistent.

>> 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.

Well, we'll just agree to disagree. Nothing made by a human is never going to be as consistent
as an automated process. If I can get the sha1 for the release in an automated way, I'm not
going to cut and paste it from somewhere. I already grabbed the wrong one already in one of
the releases. There is no way you're going to convince me that once a tool has been validated
to yield the correct information that making a manual email is better.

> 
>> 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.
> 

You have the SCM coordinates now. Is the issue not addressed with the tool I made? There is
no way that you will be able manually review the release as accurately as the tool. You think
it's useful to go file by file and manually check all the files? That you are going to do
it consistently and accurately without tooling? If you want to, all the information will be
there in the releases I do from now on from the report I'm generating and it's accurate and
not susceptible to my cut/paste errors.

If from the staging process the email is emitted along with the report then you can do anything
manually you wish but everything to that point will have been created in a consistent, repeatable
way that can be performed by someone else (at least when I'm done).

> The vote e-mail chain is the official means by which releases are sanctioned.

I have no issue sending an email.

> 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.
> 

Are you manually going to go through each of our releases file by file? If you are I will
ask to put the revision in the template. After looking, and making the tool I don't think
it's necessary. But if you are going to use no tooling and essentially do what I automated
I will ask to add the source revision in the email. If this is for a theoretical reviewer
who may want to do it, then I honestly don't think it's useful or necessary.

>>> 
>>>> 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
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------








Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message