On 25 June 2013 19:19, 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. 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.
The only way to know which version of the tag is relevant is to work out which tag happened to be present when the vote took place. Since SVN tags are not physically immutable, they must be identified with the revision. Why make a fuss over providing the info - which is readily available to the RM from the commit message - when it makes it so much easier in retrospect to know what was voted on. Also if there are several versions of a tag and vote threads - as happens frequently - it can be very difficult untangling which is which, as they can easily overlap in time if people have not caught up fully with their e-mail. It needs to be absolutely clear what reviewers are voting on, both at the time, and later on when memories have faded. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
