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.go...@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.go...@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.go...@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-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
