sebb wrote:
On 10/01/2008, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On Jan 10, 2008 4:32 PM, sebb <[EMAIL PROTECTED]> wrote:
On 10/01/2008, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
---- Original Message ----
From: Jochen Wiedmann <[EMAIL PROTECTED]>
On 10/01/2008, Stephen Colebourne <[EMAIL PROTECTED]>
wrote:
[..]
+1 to this sentiment. I completely reject the notion of generating
NOTICE.txt. That is our responsibility here in commons.
And I reject the attitude to discard a solution *once and forever*,
simply because there is an aspect in the *current* implementation that
you dislike.
My position is that no matter how good the plugin is, the NOTICE file
needs to be generated manually in order to ensure proper oversight. It
seems to me that it should be possible to review the NOTICE file for
compliance without having to generate it.
Oversight is the PMC reviewing and voting on the release artifacts and
checking the LICENSE and NOTICE files - even if theres a good
hand-written copy in svn it makes no difference since its what we put
out in our distros.
OK, point taken.
Additionally hand written ones can be just as bad
or worse. If a component has the "standard" flavour that most of our
components have why does that make you feel confident? For all you
know someones just copied another and has given no thought to what it
should contain. At least with the generated one it tries to name all
dependencies, the author and license - if that doesn't work well then
putting in a custom "hand written" one takes precedence over the
generated one. So it seems to me this plugin is better IF the
dependencies information is up to date.
AIUI, the NOTICE file is not about dependencies, it is about the
artefacts that are actually included in the distribution.
In the case of Commons, dependencies are normally not included in the
distribution, and should therefore not be included in NOTICE.
Now I better understand why you feel the way you do about this.
The approach that mrrp takes is to inform about software that is either
included *or* used by the current project. So it behaves differently
than you expect it to. I don't have much insight into the legal stuff
surrounding these files, but mrrp is used by lots of ASF project. So I
suspect that the generated NOTICE files comply with ASF policy.
Indeed, I suspect that most (possibly all) Commons distributions need
the same NOTICE file - the only difference being the initial copyright
year.
Or have I missed something here?
Niall
This is what I also said, and got snipped:
"Whether this affects a particular plugin or not is of non relevance to
me."
ie. I personally have no idea what the rest of the plugin does, its not of
great interest to me. My point is specific to NOTICE.txt. To a lesser degree it
also affects LICENSE.txt, which should also be in svn IMO.
Stephen
The value of the mrr plugin (in the light of the Apache policies) is
that it provides the technical solution for a non-trivial task: To
ensure that artifacts contain the required files. Having been the
person who was forced to implement a comparable solution in the past
for a several projects and for several artifacts separately, I am very
happy if someone provides a solution that does exactly that and will
take care for possible other artifacts in the future. The question,
how and from where the NOTICE.txt file is obtained is a minor problem,
which can easily be achieved, in the worst case by subclassing the
plugin. So, what's the reason to be so gruff?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
