maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
Date Sun, 07 Jul 2013 20:32:41 GMT
Le dimanche 7 juillet 2013 20:53:02 sebb a écrit :
> On 7 July 2013 20:39, Arnaud Héritier <aheritier@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 <sebbaz@gmail.com> wrote:
> >> On 7 July 2013 13:45, Chris Graham <chrisgwarp@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> > 
> > --
> > -----
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message