Le dimanche 7 juillet 2013 20:53:02 sebb a écrit : > 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 the actual *process* is not in fault: there is a bug in the implementation for this artifact, and we need to continue to improve it
> > > 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. the tag is in the site provided in the vote, in the mailing lists, immediately defined by convention, and so on: this info is really not difficult to find, absolutely requesting this info explicitely in the mail vote is really IMHO some form of extremism > > > 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. as far as the process is reproducible, I don't have any problem if sometimes the result isn't magically as expected: it's like every bug we find and fix > > > * 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. no problem for people to use whatever tool they want to help them Regards, Hervé > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
