On 26 November 2012 17:41, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Traceability by who? > > PMC members can easily verify that what is committed to dist matches what > they verified using what they downloaded and the MD5s that came with them. > They are the ones responsible for the vote and the artifacts so I don't see a > problem with that. Why you would need some sort of formal linking once the > artifacts are published escapes me.
The point is that using the SVN URL+revsion in the vote thread automatically identifies a unique set of artifacts, and is a single item to check. Yes, it is possible to trace files using a hash (apart from the occasional collisions), but the voters would have to check every single hash against the e-mail and the artifact in order to tie the artifacts to the vote. And the same would have to be done for the files once published. This is tedious, and unlikely to be done by all voters (and how many RMs provide the hashes?). Whereas even if the voters don't check the SVN revision, provided that the URL was not recreated within the time-frame of the vote, it would be possible to prove which set of artifacts was voted on. If an RM publishes a release with a valid PMC vote, then the ASF provides legal protection if necessary. AIUI this can only apply if the rules have been followed. Having traceability allows the RM and ASF to prove that the released artifacts were the ones voted on, should it prove necessary. At present it would be very easy to accidentally release a file from the wrong upload directory, e.g. if there were several RCs. > Ralph > > > On Nov 26, 2012, at 9:23 AM, sebb wrote: > >> On 26 November 2012 17:01, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> Actually, if you use the Release plugin the artifacts will be uploaded to >>> the staging repository. At least that is what VFS does. They can be voted >>> on there and then checked into SVN. You can easily verify they didn't >>> change because the MD5s go along with them. >> >> But do the MD5s get automatically added to the release vote? >> And how can one prove later that the MD5s in the VOTE thread are the >> same as the ones in the staging repo? >> >> AFAICT that is no different from uploading to anywhere else, unless I >> misunderstand what the release staging repository is. >> >> The point is that uploading to SVN and voting on the URL+revision >> automatically provides traceability. >> Whereas AFAICT the other methods don't, at least not without >> additional work by the RM and all reviewers. >> >>> Ralph >>> >>> On Nov 26, 2012, at 8:41 AM, sebb wrote: >>> >>>> On 26 November 2012 11:24, sebb <seb...@gmail.com> wrote: >>>>> On 26 November 2012 09:53, Emmanuel Bourg <ebo...@apache.org> wrote: >>>>>> Le 26/11/2012 01:01, sebb a écrit : >>>>>> >>>>>>> Hope this all makes sense! >>>>>> >>>>>> Well, maybe I misunderstood, but committing the RC sites for review into >>>>>> a SVN repository seems a bit convoluted to me. A good old upload on >>>>>> people.apache.org was perfectly fine. >>>>> >>>>> AIUI that's what infra want. >>>> >>>> If the dist/dev URL (plus revision) is used in the vote thread, it's >>>> possible to easily trace the files from the ASF mirror back to the >>>> actual files used in the vote. >>>> >>>> This is not nearly so easy if the files are just uploaded to a user >>>> directory on minotaur - there's no proof that the the files that were >>>> voted on are the ones that were eventually released. >>>> >>>> At some point the files must be uploaded to SVN; once in SVN they can >>>> be moved around very cheaply. >>>> >>>>>> Emmanuel Bourg >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
