maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Release Apache Maven Model Converter version 2.3
Date Fri, 16 Aug 2013 13:27:37 GMT
On 16 August 2013 13:44, Stephen Connolly
<stephen.alan.connolly@gmail.com> wrote:
> r1514680
>
> Does that, coupled with the knowledge that our source release bundles are
> *supposed to* include the tag details that they were built from resolve
> your issue?

Sorry, but no.

As I see it, release votes should be independent of the tooling and
project layout etc.

What's important is that the source release can be demonstrated to be
derived entirely from "approved" sources.

So any ASF vote email should contain:

+ Pointer to the "approved" original source files, i.e. unique SCM coordinates

+ Pointer to the release candidate source archive(s), plus hash(es) to
make the instance unique and traceable

+ Pointer to the KEYS file so sigs can be checked.

+ Pointers to binary (and javadoc) archives, if any.
These are not part of a formal ASF release, but if they are provided
then their N&L files must be present and correct.

Reviewers should not be required to understand the release tooling or
even how to build or test the application.
These are not necessary for the the parts of the review which only
look at provenance and licensing.

Of course the PMC does have an interest in additional aspects of the
release, such as documentation, does it build and test OK.
For those parts of the review of course more detailed knowledge of the
project is needed.

For the requirements of ASF releases, a reviewer only needs to know how to:
- obtain the "approved" source files
- inspect the release candidate archives so the contents can be
checked and compared as necessary.
- check sigs and hashes

> (Obviously there is more tooling we can add... for instance I suspect that
> for GIT we are not including the git hash that release:perform is running
> from... which is something I think we can address)
>
>
> On 16 August 2013 13:17, sebb <sebbaz@gmail.com> wrote:
>
>> On 16 August 2013 13:08, Fred Cooke <fred.cooke@gmail.com> wrote:
>> > They're deployed as a set, so what I want is the SHA1 or even MD5 of any
>> > one of the set of uploaded files, such that I can confirm that the set is
>> > the set that I am supposed to be looking at. I don't see importance in
>> > which, but I've not thought about it much. I think *all* would be huge
>> > overkill.
>>
>> It's only really needed for source archives, which are the ones being
>> officially voted on.
>>
>> This is something I've long thought is necessary to be able to tie the
>> vote mail to the artifacts.
>>
>> And it could be very useful to have the hash in the mail archive.
>>
>> > On Sat, Aug 17, 2013 at 12:00 AM, Stephen Connolly <
>> > stephen.alan.connolly@gmail.com> wrote:
>> >
>> >> That sounds like you are looking for the SHA1 sum of the source bundle
>> to
>> >> be included in the vote email. Which would seem perfectly reasonable to
>> me.
>>
>> Yes please!
>>
>> >>
>> >>
>> >>
>> >>
>> >> On 16 August 2013 12:31, Fred Cooke <fred.cooke@gmail.com> wrote:
>> >>
>> >> > Dennis, of course source bundles will contain URLs and hashes and
>> >> revisions
>> >> > and so forth, and the chance of those being mismatched is
>> approximately
>> >> > zero. That's not the point.
>> >> >
>> >> > The point (for me, at least) is what did you INTEND to release, and
>> does
>> >> > THAT match what is actually found in the bundle (including URLs and
>> >> hashes
>> >> > etc matching).
>> >> >
>> >> > Releasing is a fundamentally human process that consists of "is this
>> >> > ready?" and "pull trigger". Some binaries and bundles end up on
>> server of
>> >> > some type somewhere. I want to know the checksum of one of the set
of
>> >> items
>> >> > (so I KNOW (not guess) that I'm looking at what you want me to), and
I
>> >> want
>> >> > to know what SCM or tarball+patchset you think you released it from.
>> This
>> >> > is human information that can't be automated. The bundle someone goes
>> and
>> >> > finds could have anything in it, and they won't know if it's what you
>> >> > wanted it to have in it, or not.
>> >> >
>> >> > Fred.
>> >> >
>> >> > On Fri, Aug 16, 2013 at 11:25 PM, Dennis Lundberg <dennisl@apache.org
>> >> > >wrote:
>> >> >
>> >> > > On Fri, Aug 16, 2013 at 11:24 AM, sebb <sebbaz@gmail.com>
wrote:
>> >> > >
>> >> > > > On 16 August 2013 09:32, Dennis Lundberg <dennisl@apache.org>
>> wrote:
>> >> > > > > On Fri, Aug 16, 2013 at 9:52 AM, sebb <sebbaz@gmail.com>
wrote:
>> >> > > > >
>> >> > > > >> On 16 August 2013 08:10, Dennis Lundberg <dennisl@apache.org>
>> >> > wrote:
>> >> > > > >> > On Fri, Aug 16, 2013 at 1:20 AM, sebb <sebbaz@gmail.com>
>> wrote:
>> >> > > > >> >
>> >> > > > >> >> On 15 August 2013 20:57, Dennis Lundberg
<
>> dennisl@apache.org>
>> >> > > wrote:
>> >> > > > >> >> > On Thu, Aug 15, 2013 at 9:27 PM, sebb
<sebbaz@gmail.com>
>> >> > wrote:
>> >> > > > >> >> >
>> >> > > > >> >> >> On 15 August 2013 14:16, Jason
van Zyl <jason@tesla.io>
>> >> > wrote:
>> >> > > > >> >> >> > What Sebb is doing is perfectly
reasonable.
>> >> > > > >> >> >>
>> >> > > > >> >> >
>> >> > > > >> >> > I agree. Checking that the source
bundle is correct is
>> good
>> >> > > release
>> >> > > > >> >> review
>> >> > > > >> >> > practice.
>> >> > > > >> >> >
>> >> > > > >> >> > Thank you!
>> >> > > > >> >> >>
>> >> > > > >> >> >> > 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.
>> >> > > > >> >> >>
>> >> > > > >> >> >> It *has* already happened several
times that I am aware
>> of.
>> >> > > > >> >> >>
>> >> > > > >> >> >> The last few releases of the War
plugin (various RMs &
>> >> voters)
>> >> > > > >> >> >> included at least one spurious
file.
>> >> > > > >> >> >> So it was not just a one-off packaging
- and review -
>> >> failure.
>> >> > > > >> >> >> [See separate thread(s) for all
the details; they are not
>> >> > > germane
>> >> > > > >> here.]
>> >> > > > >> >> >>
>> >> > > > >> >> >> The message is that mistakes happen
even in automated
>> >> > processes.
>> >> > > > >> >> >> Which is why independent comparison
of input and output
>> is
>> >> > > > valuable.
>> >> > > > >> >> >>
>> >> > > > >> >> >> > 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?
>> >> > > > >> >> >>
>> >> > > > >> >> >> Yes.
>> >> > > > >> >> >>
>> >> > > > >> >> >> One other point I made already
is that I think the vote
>> >> e-mail
>> >> > > > needs
>> >> > > > >> >> >> to be transparent to all, not
just those on the PMC.
>> >> > > > >> >> >> Links to the output from the release
process are
>> obviously
>> >> > > > already in
>> >> > > > >> >> >> the mail; what is missing is the
input to the process,
>> e.g..
>> >> > SCM
>> >> > > > >> >> >> coords.
>> >> > > > >> >> >> Yes, it may be possible to dig
out the details from the
>> >> > archive,
>> >> > > > but
>> >> > > > >> >> >> that's not trivial.
>> >> > > > >> >> >>
>> >> > > > >> >> >
>> >> > > > >> >> > I disagree.
>> >> > > > >> >> >
>> >> > > > >> >> > If we focus first on a "normal" release,
one that
>> succeeds on
>> >> > the
>> >> > > > >> first
>> >> > > > >> >> > attempt, without a respin or deleting
of tags.
>> >> > > > >> >> > To check provenance you would do this:
>> >> > > > >> >> >
>> >> > > > >> >> > 1. download the source bundle
>> >> > > > >> >> > 2. unpack the source bundle
>> >> > > > >> >> > 3. checkout the corresponding source
code from the SCM
>> >> > > > >> >> > 4. compare the two trees
>> >> > > > >> >> >
>> >> > > > >> >> > Right so far?
>> >> > > > >> >> >
>> >> > > > >> >> > What you want, if I understand you
correctly, is to have
>> the
>> >> > SCM
>> >> > > > URL
>> >> > > > >> in
>> >> > > > >> >> the
>> >> > > > >> >> > vote email. So that you can give that
to your SCM client
>> in
>> >> > step
>> >> > > 3.
>> >> > > > >> >>
>> >> > > > >> >> Yes.
>> >> > > > >> >>
>> >> > > > >> >> > With the process we use here at the
Maven project, the SCM
>> >> URL
>> >> > is
>> >> > > > in
>> >> > > > >> the
>> >> > > > >> >> > pom.xml file that sits in the root
directory of the
>> unpacked
>> >> > > source
>> >> > > > >> >> bundle.
>> >> > > > >> >> > All you need to do is open the file
and copy the URL from
>> >> > there.
>> >> > > I
>> >> > > > >> still
>> >> > > > >> >> > fail to see how that is so much harder
than to copy the
>> URL
>> >> > from
>> >> > > an
>> >> > > > >> >> email.
>> >> > > > >> >> >
>> >> > > > >> >> > That is if you don't know the conventions
that we use, by
>> way
>> >> > of
>> >> > > > the
>> >> > > > >> >> > Release Plugin. The tag will always
be in the format
>> >> > > > >> >> > ${project.artifactId}-${project.version}
>> >> > > > >> >> >
>> >> > > > >> >>
>> >> > > > >> >> My point is that it should be completely
transparent, even
>> to
>> >> > > outside
>> >> > > > >> >> reviewers.
>> >> > > > >> >>
>> >> > > > >> >
>> >> > > > >> > I guess that this is the point that we'll have
to agree to
>> >> > disagree
>> >> > > > on.
>> >> > > > >> My
>> >> > > > >> > view is that if someone wants to to review
a release from the
>> >> > Maven
>> >> > > > >> > project, they'd have to have a basic understanding
of how
>> Maven
>> >> > > works
>> >> > > > and
>> >> > > > >> > how we do releases in the Maven project. That
includes what
>> the
>> >> > > > Release
>> >> > > > >> > Plugin is and how it works.
>> >> > > > >>
>> >> > > > >> Why does the release tool matter?
>> >> > > > >>
>> >> > > > >
>> >> > > > > It is not the tool itself that matters, but rather what
the
>> tools
>> >> > does.
>> >> > > > > Since the Release plugin automates a lot of the tasks
involved
>> when
>> >> > > > doing a
>> >> > > > > release, it can appear to make things less transparent.
>> Therefor a
>> >> > > > > knowledge about what it does is needed to make it transparent.
>> >> > > >
>> >> > > > That really is not the point.
>> >> > > >
>> >> > > > It's possible to create the same outputs from the same inputs
>> using
>> >> > > > all sorts of methods, manual or automated.
>> >> > > >
>> >> > > > The fact that it is a Maven release should not matter as
far as
>> the
>> >> > > > source checking is concerned, except insofar as the staging
area
>> may
>> >> > > > be different.
>> >> > > >
>> >> > > > Only the source release archives matter.
>> >> > > >
>> >> > >
>> >> > > All of what you say above is true, but that is not what I'm talking
>> >> > about.
>> >> > > My focus is still on the 2.5 bullet in the process of *reviewing*
a
>> >> > source
>> >> > > release, not it's creation.
>> >> > >
>> >> > > You want the SCM URL in the vote email. I'm arguing that that
piece
>> of
>> >> > > information is already available to you in the source bundle,
so
>> there
>> >> is
>> >> > > not point in including it in the vote email. Knowing *what* the
>> Release
>> >> > > Plugin does makes you aware of this fact.
>> >> > >
>> >> > >
>> >> > > >
>> >> > > > > It's still an ASF release.
>> >> > > > >>
>> >> > > > >
>> >> > > > > Yes, and we must adhere to all the requirements of an
ASF
>> release.
>> >> > > There
>> >> > > > > are however a lot of different ways to make an ASF compliant
>> >> release.
>> >> > > > Each
>> >> > > > > PMC decides on a process for that, that works best for
them.
>> >> > > >
>> >> > > > That's fine, the tool and process does not matter so long
as the
>> >> > > > output is correct.
>> >> > > >
>> >> > > > > It should not matter how the source release artifacts
are
>> >> generated.
>> >> > > > >> The process of checking them is still the same.
>> >> > > > >>
>> >> > > > >> Of course if things go wrong, then it's important
to know how
>> the
>> >> > SCM
>> >> > > > >> input was assembled into the source archives in
order to fix
>> the
>> >> > > > >> process.
>> >> > > > >> But the release tool is completely irrelevant to
the process of
>> >> > > > >> checking the contents of the source archives.
>> >> > > > >>
>> >> > > > >
>> >> > > > > See above.
>> >> > > > >
>> >> > > > >
>> >> > > > >>
>> >> > > > >> > Most people have their own checklist of stuff
they do when
>> >> > > reviewing a
>> >> > > > >> > release. Would it be a good idea if we aggregate
all those
>> >> points
>> >> > > on a
>> >> > > > >> page
>> >> > > > >> > on the Maven web site, under the development
section? That
>> would
>> >> > > also
>> >> > > > >> serve
>> >> > > > >> > as a guide for "outside reviewers".
>> >> > > > >>
>> >> > > > >> Yes, though that is a separate issue.
>> >> > > > >>
>> >> > > > >
>> >> > > > > Agreed.
>> >> > > > >
>> >> > > > >>
>> >> > > > >> >> > Now, for a respun release thing are
trickier. Here it
>> might
>> >> be
>> >> > a
>> >> > > > good
>> >> > > > >> >> idea
>> >> > > > >> >> > to include the revision number or
hash, or whatever is
>> unique
>> >> > in
>> >> > > > the
>> >> > > > >> SCM
>> >> > > > >> >> > being used.
>> >> > > > >> >>
>> >> > > > >> >> And how do you know from a vote e-mail
that it is respun?
>> >> > > > >> >>
>> >> > > > >> >
>> >> > > > >> > It should always say so in the subject of the
vote email. Not
>> >> sure
>> >> > > if
>> >> > > > >> that
>> >> > > > >> > is written down somewhere, but that's how we
have always done
>> >> it.
>> >> > If
>> >> > > > it's
>> >> > > > >> > missing I'll add it to our release process
document.
>> >> > > > >> >
>> >> > > > >> >
>> >> > > > >> >>
>> >> > > > >> >> > Even though the code under review
will always be under the
>> >> > > > >> >> > latest tag in the above format (at
least for Subversion).
>> >> > > > >> >>
>> >> > > > >> >> Until the next respin.
>> >> > > > >> >>
>> >> > > > >> >> If there is a respin, and reviewers are
not following the
>> >> e-mails
>> >> > > > very
>> >> > > > >> >> carefully, it would be quite easy to overlook
an updated
>> tag.
>> >> > > > >> >>
>> >> > > > >> >> This is all about making sure that it is
really obvious what
>> >> the
>> >> > > > vote is
>> >> > > > >> >> about.
>> >> > > > >> >>
>> >> > > > >> >
>> >> > > > >> > Yes, that's why I agreed that it's a good idea
to add the
>> >> > > > revision/hash
>> >> > > > >> > when doing a respin.
>> >> > > > >> >
>> >> > > > >> >
>> >> > > > >> >>
>> >> > > > >> >> >
>> >> > > > >> >> >> Publishing the SCM coordinates
in the mail is trivial to
>> do,
>> >> > and
>> >> > > > >> shows
>> >> > > > >> >> >> that the input is an important
part of the review
>> process.
>> >> > > > >> >> >> Having the information in the
mail thread is also useful
>> for
>> >> > the
>> >> > > > >> >> archives.
>> >> > > > >> >> >>
>> >> > > > >> >> >
>> >> > > > >> >> > As others have said before, we aim
to automate the release
>> >> > > process
>> >> > > > as
>> >> > > > >> >> much
>> >> > > > >> >> > as possible. Therefor even a seemingly
minor addition
>> will be
>> >> > > > >> questioned,
>> >> > > > >> >> > as you have noticed, before it is
included in our process.
>> >> > > > >> >> >
>> >> > > > >> >> > Can you explain why the information
is useful for the
>> >> archives?
>> >> > > > I've
>> >> > > > >> seen
>> >> > > > >> >> > you mentioned that before. Isn't that
moot once the
>> release
>> >> is
>> >> > > > >> approved?
>> >> > > > >> >> > The tag will be in Subversion for
the forseable future and
>> >> > noone
>> >> > > > will
>> >> > > > >> >> touch
>> >> > > > >> >> > it. What am I missing?
>> >> > > > >> >>
>> >> > > > >> >> Why would a release need to be revisited?
>> >> > > > >> >> Perhaps someone is complaining that one
of our releases
>> >> contains
>> >> > > code
>> >> > > > >> >> it should not.
>> >> > > > >> >> If that is the case, it helps to have the
evidence of the
>> >> release
>> >> > > > vote
>> >> > > > >> >> in plain sight.
>> >> > > > >> >>
>> >> > > > >> >
>> >> > > > >> > Sure it helps in those cases. But the evidence
in our case
>> is in
>> >> > the
>> >> > > > the
>> >> > > > >> > source bundle itself, which is even better
in my opinion.
>> There
>> >> > you
>> >> > > > have
>> >> > > > >> > the tag in the POM file.
>> >> > > > >>
>> >> > > > >> However, the link to the staging repo is temporary.
>> >> > > > >> Once the repo is published, the staging repo is
deleted and
>> there
>> >> is
>> >> > > > >> no direct route to the pom from the vote e-mail.
>> >> > > > >>
>> >> > > > >
>> >> > > > > Once the staging repo is promoted, its content is moved
to the
>> real
>> >> > > > > repository. So the source bundle is available there
for anyone
>> who
>> >> > > wants
>> >> > > > to
>> >> > > > > track down the complete contents of a previous release.
>> >> > > >
>> >> > > > However that is not the canonical location for source releases;
>> >> source
>> >> > > > releases MUST be released via the ASF mirror system.
>> >> > > >
>> >> > >
>> >> > > So, go download it from the mirror system then. I fail to see
how
>> that
>> >> is
>> >> > > relevant to this discussion.
>> >> > >
>> >> > >
>> >> > > > > Again this is where a bit of knowledge of what the Release
>> Plugin
>> >> > does
>> >> > > > > helps you. A release done with the Release Plugin will
always be
>> >> > > > available
>> >> > > > > at
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://repository.apache.org/content/repositories/releases/${project.groupId}/${project.artifactId}/${project.version}/${project.artifactId}-${project.version}-source-release.zip
>> >> > > > > where project.groupId has had '.' replaced by '/'.
>> >> > > >
>> >> > > > AIUI the name is not controlled by the Release Plugin.
>> >> > > >
>> >> > > > The first part of the name is determined by Maven Convention
and
>> ASF
>> >> > > > hosting.
>> >> > > > The -source-release.zip suffix depends on settings outside
the
>> >> Release
>> >> > > > plugin.
>> >> > > >
>> >> > > > Apache Commons sometimes uses the Release Plugin, but our
archives
>> >> are
>> >> > > > called -src.zip and -src.tar.gz
>> >> > > >
>> >> > >
>> >> > > Okay, I'll rephrase that:
>> >> > >
>> >> > > Again this is where a bit of knowledge of what the Release Plugin
>> does
>> >> > > *during a release from the Apache Maven project* does help you.
>> >> > >
>> >> > > Is that clear enough?
>> >> > >
>> >> > >
>> >> > > >
>> >> > > > >
>> >> > > > >> > Note that I'm not talking about respins here,
that's another
>> >> > story.
>> >> > > > >>
>> >> > > > >> >
>> >> > > > >> >>
>> >> > > > >> >> >
>> >> > > > >> >> >>
>> >> > > > >> >> >> > On Aug 15, 2013, at 9:01
AM, Chris Graham <
>> >> > > chrisgwarp@gmail.com
>> >> > > > >
>> >> > > > >> >> wrote:
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >>
>> >> > > > >> >> >> >>
>> >> > > > >> >> >> >> Sent from my iPhone
>> >> > > > >> >> >> >>
>> >> > > > >> >> >> >> On 15/08/2013, at 10:05
PM, sebb <sebbaz@gmail.com>
>> >> wrote:
>> >> > > > >> >> >> >>
>> >> > > > >> >> >> >>> On 15 August 2013
10:08, Chris Graham <
>> >> > chrisgwarp@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-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
>> >> > > > >> >> >> >>
>> >> > > > >> >> >> >
>> >> > > > >> >> >> > 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
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >> >
>> >> > > > >> >> >>
>> >> > > > >> >> >>
>> >> > > >
>> ---------------------------------------------------------------------
>> >> > > > >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > > >> >> >> For additional commands, e-mail:
>> dev-help@maven.apache.org
>> >> > > > >> >> >>
>> >> > > > >> >> >> --
>> >> > > > >> >> >> Dennis Lundberg <dev-help@maven.apache.org>
>> >> > > > >> >> >>
>> >> > > > >> >>
>> >> > > > >> >>
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> > > > >> >>
>> >> > > > >> >> --
>> >> > > > >> >> Dennis Lundberg <dev-help@maven.apache.org>
>> >> > > > >> >>
>> >> > > > >>
>> >> > > > >>
>> >> > ---------------------------------------------------------------------
>> >> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> > > > >>
>> >> > > > >> --
>> >> > > > >> Dennis Lundberg <dev-help@maven.apache.org>
>> >> > > > >>
>> >> > > >
>> >> > > >
>> ---------------------------------------------------------------------
>> >> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > > >
>> >> > > > --
>> >> > > > Dennis Lundberg <dev-help@maven.apache.org>
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> 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