On 7 July 2013 20:39, Arnaud Héritier <aherit...@gmail.com> wrote: > I understand the issue but for me all that problems will never disappear if > we don't find a solution to automate the process.
The point is that processes and people are not infallible > Yes PMCs (and devs) are responsible to do various controls as you mentioned > but I suppose that we aren't different to others projects and our time > spent in OSS projects is often limited. It does not take long to do a comparison - assuming that the tag is provided in the vote e-mail. > About the problem of sources content I have two things in mind : > * The release:perform goal is doing a checkout of the tag and then does the > build/deploy of released stuffs. The problem is that the assembly which is > creating the sources archive is doing it after the build instead of doing > it just after the checkout. How could we change this to be sure that in the > archive we just have what we just checkouted ? That would reduce the window of opportunity for errors, but I'm convinced that Murphy's law can be entirely avoided. > * We could add a control (enforcer ?) that will compare the content of an > archive with an scm tag checkout There is already a Perl tool to compare directory structures: https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl I use that, as well as a GUI compare tool. > Arnaud > > > On Sun, Jul 7, 2013 at 9:31 PM, sebb <seb...@gmail.com> wrote: > >> On 7 July 2013 13:45, Chris Graham <chrisgw...@gmail.com> wrote: >> > In this instance, these files are derived files, so does it matter? >> >> I already said that this particular file is probably not an issue. >> >> The issue is that the release process is clearly not infallible. >> >> The assembly plugin does not identify every file it needs to include, >> so spurious files can be picked up if they happen to be in the wrong >> place. >> As happened here. >> Furthermore, AFAIK it does not report include failures, so a required >> file could be omitted. >> In this case, there was an issue with a test creating the spurious >> file. If test cases delete work files after use, it's not impossible >> to imagine that the wrong file is deleted. >> >> But regardless of the process used to create the release candidate, I >> think the way to check whether it has the correct contents is to >> compare it against the SCM from which it was derived. The comparison >> will identify missing and spurious files. >> Files that match the SCM also have a traceable provenance, and SCM >> files should already have been validated for license compatibility. >> >> I see this as basic quality control. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
