On 14 August 2013 11:13, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > On 14 August 2013 10:45, sebb <seb...@gmail.com> wrote: > >> On 14 August 2013 10:23, Stephen Connolly <steph...@apache.org> wrote: >> > On 14 August 2013 09:47, sebb <seb...@gmail.com> wrote: >> > >> >> On 13 August 2013 18:58, Dennis Lundberg <denn...@apache.org> wrote: >> >> > On Tue, Aug 13, 2013 at 12:30 AM, sebb <seb...@gmail.com> wrote: >> >> >> On 12 August 2013 20:10, Jason van Zyl <ja...@tesla.io> wrote: >> >> >>> >> >> >>>>> >> >> >>>>> I have now read the threads that are referring to, and have not >> found >> >> >>>>> a single link to any ASF rule stating that we need to include >> these >> >> >>>>> things in a VOTE thread. >> >> >>>> >> >> >>>> So how do you propose that reviewers check the provenance of the >> files >> >> >>>> in the source release? >> >> >>> >> >> >>> Are you looking for files that are in a distribution that didn't >> come >> >> from source control? Everything else as far as provenance goes is >> covered. >> >> Errant content is a potential problem, but everything in a distribution >> >> should come from source control which no one has access to until they >> have >> >> a signed CLA on file. >> >> >> >> >> >> Yes. That is where the whole saga started. >> >> >> >> >> >> Proving provenance is why the SCM coordinates are needed for the >> vote. >> >> >> >> >> >> The SCM details may also be useful to discover files accidentally >> >> >> omitted from the source archive. >> >> > >> >> > You want to compare the contents of the *-source-release.zip with >> >> > something from SCM, to make nothing bad has crept into the source >> >> > bundle. So you need to know where in SCM you can find it. Have I >> >> > understood you correctly? >> >> >> >> It's vital to be able to link the files in the source release >> >> archive(s) to their origin in SCM. >> >> >> > >> > Simply not true. It is a nice convenience for somebody tracing the >> > provenance of files in a source release, but it is by no means vital. >> > >> >> What other means do you suggest then? >> > > That is not *your problem*. That is the *reviewers* problem. If the PMC > reviewers decide that determining the provenance of files (which is a > necessary part of their review) is too difficult because they are missing > information that would assist them, then *they* will drive adding that > information.
As a member of the ASF, I do think it's my problem if software is being released in the name of the ASF. The ASF is about transparency - "if it did not happen on a public mailing list then it did not happen". It should be possible for anyone to review a release and provide feedback to the PMC. At present the process is not transparent. > >> > >> >> >> >> The provenance of any source files the ASF releases must be clearly >> >> traceable. >> >> >> > >> > Being able to link the files in the source release archive(s) to their >> > origin in SCM is certainly one way to make the provenance of source files >> > the ASF releases easily traceable, but there is *no* foundation >> requirement >> > for such. >> >> Is there any other way to check provenance? >> > > It is up to each individual PMC to put in place the procedure by which they > check the provenance of the files they release, thus if a PMC decides to > forgo SCM and return to the original HTTPD model of just releasing tarballs > then the Foundation will require that they determine a method through which > they can establish the provenance of the files they are releasing. > > >> >> > As I understand it, we *could*, as a project, decide to abandon SCM >> > entirely for some specific module - something I would be strongly >> against - >> > and we would be within our rights to do so. >> > >> > All that the foundation requires is that the PMC have verified the >> > provenance of the files in the source releases they vote on. >> >> Which is not currently possible with the information provided in the >> vote e-mail. >> > > The PMC members do not see a problem. > > >> >> > If you feel that individual members of the PMC are voting without having >> > taken their required due diligence into account then I suggest you take >> > that up with those individual members. >> >> I just want to make sure that the reviewers have the information they >> need to be able to do the due diligence. >> At present that is not possible from the information provided in the >> vote e-mails. >> > > Again, the PMC are the reviewers that are required to perform their due > diligence and do not see an issue with the email content. > > We see that we have all the information we require, we also do not want to > add extra information than is required by us. > -Stephen > > >> >> > -Stephen >> > >> > >> >> >> >> >>> Thanks, >> >> >>> >> >> >>> Jason >> >> >>> >> >> >>> ---------------------------------------------------------- >> >> >>> Jason van Zyl >> >> >>> Founder, Apache Maven >> >> >>> http://twitter.com/jvanzyl >> >> >>> --------------------------------------------------------- >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Dennis Lundberg >> >> > >> >> > --------------------------------------------------------------------- >> >> > 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
