maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Release process updates
Date Thu, 27 Jun 2013 14:42:16 GMT
On 27 June 2013 15:05, Ralph Goers <rgoers@apache.org> wrote:
> I do not believe that can be done with the release plugins as the pom has to specify
the same version as the tag.  If you then rename the tag you would have to modify the poms
in the tag, which makes the release invalid.
>
> Have you ever used the release plugin?  If not, I would suggest you try it and offer
up patches to change it instead of carrying on this discussion as it is unlikely maven is
going to stop using the release plugin.

This is straying further off the original topic.

Whether people use the release plugin or some other method is not
really relevant to the release vote itself.

All the process that leads up to the vote is merely a means to trying
to ensure that the release candidate as as good as possible.

What matters is the vote - the public declaration that the RC has been
reviewed and approved.
Only a PMC-approved vote can get the legal protection of the ASF.

The vote needs to be performed on input that can be readily checked by
any reviewer.
The vote has to be seen to be open and complete.
The SVN (or GIT) coordinate is an essential part of the input, as it
is the only practical way to check provenance of the files in the
archives.

Given that part of the Maven philisophy is to ensure that all plugin
versions must be specified to ensure repeatable builds, I'm a bit
surprised how much resistance there is to providing the specific
source which was used as input to the build process.

The only change that this requires to be made to the process is to add
the revision number and tag name [1] to the release vote e-mail.
Is that really too much to ask?

[1] A revision on its one is insufficient as the ASF uses a shared SVN
repo; the location within the tree is needed to be able to select the
revelant portion of the tree. The tag name is one such way to provide
the information.

> Ralph
>
> On Jun 25, 2013, at 4:14 PM, sebb <sebbaz@gmail.com> wrote:
>
>> It would be a lot better to use RC1 RC2 etc initially, and copy the
>> successful tag to the GA tag.
>>
>> On 25 June 2013 19:38, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>>> Yeah - I agree with this.  I rename them to rc1, rc2, etc after a failed release
vote instead of deleting them.
>>>
>>>
>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote:
>>>
>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers <ralph.goers@dslextreme.com>wrote:
>>>>
>>>>> Again I have to disagree.  The release manager will send an email closing
>>>>> the prior release.  At this point all the prior release artifacts are
junk
>>>>> even if they still exist.  At some point the release manager will delete
>>>>> the tag and rerun the release
>>>>
>>>>
>>>> That's a no-no IMO. Tags that have been voted on should never be deleted.
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>>> At this point the tag is still junk to everyone else because they have
no
>>>>> idea what the RM is doing - so they shouldn't be making assumptions about
>>>>> non-released tags.  Once he sends the email though the tag will be valid.
>>>>> Sure having the revision number helps but unless the RM completely screws
>>>>> up the tag should be sufficient.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote:
>>>>>
>>>>>> Not really, no. The developer may have re-spun it again and be about
to
>>>>>> email again. You have no idea what you're looking at unless you know
the
>>>>>> revision. SVN will die off within a decade and this discussion will
>>>>> become
>>>>>> critical. Better to figure out how to support proper techniques now,
>>>>> rather
>>>>>> than wait until forced to.
>>>>>>
>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers <ralph.goers@dslextreme.com
>>>>>> wrote:
>>>>>>
>>>>>>> I disagree that the revision is required.  I know that the RM
is going
>>>>> to
>>>>>>> recreate the tag with each release candidate.  Therefore, so
long as I
>>>>>>> refetch that tag for every release vote I can be confident that
I am
>>>>>>> reviewing the release contents.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote:
>>>>>>>
>>>>>>>> The mission of the ASF is to release software as source,
and to ensure
>>>>>>>> that the released source is available under the Apache Licence.
>>>>>>>>
>>>>>>>> Before a release can be approved it must be voted on by the
PMC.
>>>>>>>> The review process needs to establish that the proposed source
release
>>>>>>>> meets those aims.
>>>>>>>>
>>>>>>>> It's all but impossible for reviewers to examine every single
file in
>>>>>>>> a source archive to determine if it meets the criteria.
>>>>>>>> And it's not unknown for spurious files to creep into a release
>>>>>>>> (perhaps from a stale workspace - are releases always built
from a
>>>>>>>> fresh checkout of the tag?)
>>>>>>>>
>>>>>>>> However, PMCs are also required to check what is added to
the SCM
>>>>>>>> (SVN/Git) to make sure it meets the required license criteria.
>>>>>>>> This is done on an ongoing basis as part of reviewing check-ins
and
>>>>>>>> accepting new contributions.
>>>>>>>> So provided that all the files in the source release are
also present
>>>>>>>> in SCM, the PMC can be reasonably sure that the source release
meets
>>>>>>>> the ASF criteria.
>>>>>>>>
>>>>>>>> Without having the SCM as a database of validated files,
there are far
>>>>>>>> too many files in the average source archive to check individually.
>>>>>>>> And how would one check their provenance? The obvious way
is to
>>>>>>>> compare them with the entries in SCM.
>>>>>>>>
>>>>>>>> Therefore, I contend that a release vote does not make sense
without
>>>>>>>> the SCM tag.
>>>>>>>> In the case of SVN, since tags are not immutable, the vote
e-mail also
>>>>>>>> needs the revision.
>>>>>>>>
>>>>>>>> Whether every reviewer actually checks the source archive
against SCM
>>>>>>>> is another matter.
>>>>>>>> But if the required SCM information is not present, it would
be
>>>>>>>> difficult to argue that the RM had provided sufficient information
for
>>>>>>>> a valid review to take place.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

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


Mime
View raw message