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