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 02:44:13 GMT
On 22 September 2013 03:09, Jason van Zyl <jason@tesla.io> wrote:
> 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.

I don't care how the e-mail is created; it can be automated.

What matters is that the content is understandable and complete.

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

I did not say that.
However if a human uses an email template (as at present) the result
should be sufficiently consistent that parsing would not be too
difficult.

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

Again, I don't care how the e-mail is created, so long as it contains
all the required information in a readable format.

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

I'm not sure what you mean by that.

> Is the issue not addressed with the tool I made?

Does the tool ensure that the SCM coordinates are included in the vote email?

> There is no way that you will be able manually review the release as accurately as the
tool.

When I review a release I don't only check files and sigs and hashes.
I use a combination of tools and visual inspection.
Sometimes the inspection turns up oddities that can then be added to
the automated tooling.

> You think it's useful to go file by file and manually check all the files?

No, but it can pay to inspect some files.

> That you are going to do it consistently and accurately without tooling?

No, I never said that.

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

So long as the required information is in the vote e-mail, that's all I require.

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

I'll just point out that there have been several plugin releases using
the standard release process that added errant files to the source
archive.
Which is one reason why independent audits are needed.

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

No, but I may inspect some files.

> If you are I will ask to put the revision in the template.

Thanks, that's part of what I'm asking; the SCM URL is also needed.

> After looking, and making the tool I don't think it's necessary.

You seem to be missing the point that the vote e-mail should be
capable of independent audit.
And should contain the information needed "for the record".

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

Whether I use your tooling or some other tooling or manual inspection
is not really relevant.

The primary input to the release vote is the vote e-mail; that needs
to contain all the information needed to audit the source release, and
to tie the release vote to the release artifacts.

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

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


Mime
View raw message