maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste Mathus ...@batmat.net>
Subject Re: [VOTE] Release Maven 3.1.1
Date Thu, 12 Sep 2013 20:52:35 GMT
2013/9/12 sebb <sebbaz@gmail.com>

> On 12 September 2013 14:52, Arnaud Héritier <aheritier@gmail.com> wrote:
> > On Thu, Sep 12, 2013 at 3:44 PM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 10 September 2013 16:33, Daniel Kulp <dkulp@apache.org> wrote:
> >> >
> >> > -1
> >> >
> >> > The src.tar.gz and src.zip files have lost their top level NOTICE and
> >> LICENSE files.   This is a regression from 3.1.0 (and 3.0.5).   That
> >> definitely needs to be fixed.  I don't have time today to look into
> that,
> >> but might tomorrow if someone doesn't beat me to it.
> >>
> >> The N&L files should also be present at the top-level of SCM.
> >> That is not a release-blocker per se, however if they had been there
> >> they would likely also be in the source archives at the top-level,
> >> which is a release blocker IMO.
> >>
> >
> >
> > Like we already say I think we aren't convinced about this because it
> will
> > imply to recopy these files across ~50 projects (plugins, shared libs)
> and
> > thus update them the day we'll decide/need to do it. That's why we always
> > prefered to bundle them at build time.
>
> The point is:
> the N&L files should be at the top-level of SCM.
> That is because SCM URLs are published, so the readers need to know
> the what the license conditions are.
>

Wasn't it explained that SCM is actually a convenience, and that only the
released source tarballs would actually matter here?
In this case, Arnaud's point about only adding them at build time is really
valid here.


>
> The fact that having the N&L files there would likely have ensured
> they were in the source archive is an added bonus; it's not the
> primary reason for having them at the top-level of SCM.
>

In the source, but possibly different in many places and having to maintain
their sameness, that's again Arnaud's point.

As an external observer and a developer, not duplicating files in many
places as they should really be the same seem quite a sound PMC choice to
me.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message