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
