Dennis, effectively what is required is a statement like this: "I believe that I've released XYZ binaries from ABC sources (tarball + N patches, SCM, whatever)" with enough info to exactly identify what XYZ and ABC are (checksums, URLs, revisions, etc) without guessing and duplicated research/looking up of by everyone who wants to check.
If you just say "here's the binaries" then you have to put a LOT more work in to figure out the source to compare with, and thus trace history, and thus know that they're legit, or not. That's the problem. No statement is being made about what the release manager thinks they've released. Thus that release could be from a wrong Git branch by accident, for example or any number of other things. EG POM edited to not be snapshots and manual build done with changes made, etc. PS, it's ****ing GREAT that Jason stepped up and said what he said. Amen to that! More fine leadership. Regards, Fred. On Thu, Aug 15, 2013 at 9:37 PM, Dennis Lundberg <denn...@apache.org> wrote: > On Thu, Aug 15, 2013 at 10:50 AM, Jörg Schaible < > joerg.schai...@scalaris.com > > wrote: > > > Hi Oliver, > > > > Olivier Lamy wrote: > > > > > On 15 August 2013 08:53, sebb <seb...@gmail.com> wrote: > > >> On 14 August 2013 21:21, Dennis Lundberg <denn...@apache.org> wrote: > > >>> On Wed, Aug 14, 2013 at 10:47 AM, 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. > > >>>> > > >>>> The provenance of any source files the ASF releases must be clearly > > >>>> traceable. > > >>>> > > >>> > > >>> This information is clearly traceable and available to anyone who > wants > > >>> to review a release made by the Maven project. Our process uses the > > >>> Release Plugin, which will put the POM from the SCM tag in the > staging > > >>> directory along with the source-release.zip. In that POM wou will > find > > >>> the URL to the original sources in SCM. > > >>> > > >> > > >> As has already been pointed out, SVN tags are not immutable, so the > > >> tag name alone is not sufficient. > > > > > > I think Stephen perfectly sum up the situation. > > > If you're not happy follow that. > > > > > > But please STOP the troll! > > > > The Maven PMC has made clear, that it knows about the problems and want > to > > ignore it. However, please understand that Sebb is playing devil's > advocate > > here, because the same release process is used for other Apache projects > > where the PMCs will *not* ignore this flaws. Sebb is more or less > pestering > > you, because he is tired of having the same discussions in projects where > > he > > *is* PMC and is therefore responsible for the release. So, it is a bit > > short > > sighted to declare him as troll, simply because you (the Maven PMC) > decided > > to ignore the problem. > > > > Hi Jörg, > > Personally I'm not ignoring the problem, and I don't think anyone else is > either. > > I am trying to understand what the problem is, because I cannot see it. > Therefor I ask questions to try to find out what the problem is and then, > and only then, decide if/how to solve it. > > > > > > - Jörg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > Dennis Lundberg >
