What Sebb is doing is perfectly reasonable. He's trying to assert that everything in the source ball actually comes from source control and that no errant files have made their way into the distribution. Right now we cannot assert that the assembly plugin has not wandered outside the checkout and pulled something else in, or that someone didn't accidentally put something else in the distribution. I think this unlikely but we can't assert otherwise right now which I believe is Sebb's point.
If we can embed the revision from which the assembly was made in the assembly itself (and maybe the build number plugin is doing this already), then a tool can be made to unpack the assembly, checkout the revision and assert that everything in the source distribution comes from source control. If we can also assert that as part of each build all the license files are intact and headers are in place then I believe we're done with provenance. Licenses are present, all files have valid license headers, all files present in the source distribution come from source control, all contributions to source control are from bonafide CLA carrying Apache committers because you don't get access to commit until the CLA is on file. Sebb, reasonably accurate? On Aug 15, 2013, at 9:01 AM, Chris Graham <chrisgw...@gmail.com> wrote: > > > Sent from my iPhone > > On 15/08/2013, at 10:05 PM, sebb <seb...@gmail.com> wrote: > >> On 15 August 2013 10:08, Chris Graham <chrisgw...@gmail.com> wrote: >>> What sebb does not appear to have understood or accepted, as Stephen has >>> endlessly pointed out, is that we vote on the source bundle, not a scm >>> revision, and that, strictly speaking a SCM is not even required (however >>> sensible it is to use one). >>> >>> He wants a tree and a revision so that we can compare between releases, >>> where what he should be doing, strictly speaking, is comparing source tar >>> balls, as that is what we really are voting on. >> >> I agree that what is released (and voted on) are the source tarballs. >> And any such tarballs should be identical (barring possibly different >> EOL settings for text files). >> >> However, that is only one of the checks that need to be made. >> >> The PMC also needs to ensure that the files are being released under >> the correct license. > > Are not the licenses in the source that is in the source tarball? > > If so, can not the rat plugin or similar be used to check the compliance? > >> I contend that the only practical way to check the licences is to >> compare the source tarball(s) with the files in SCM. >> >> [The files should only be added to SCM if the license is OK, so the >> SCM tag acts as a database of validated source files.] >> >> The SVN revision / Git hash are needed to ensure uniqueness. >> >> --------------------------------------------------------------------- >> 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
