commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [IO] Planning IO 1.4 release
Date Thu, 10 Jan 2008 20:06:26 GMT
Niall Pemberton wrote:
> On Jan 10, 2008 4:32 PM, sebb <sebbaz@gmail.com> wrote:
>> On 10/01/2008, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
>>> ---- Original Message ----
>>> From: Jochen Wiedmann <jochen.wiedmann@gmail.com>
>>>> On 10/01/2008, Stephen Colebourne <scolebourne@btopenworld.com>
>>>  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. 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.

+1 to that!

And we don't have to manually remember to update copyright year in the file.

> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


-- 
Dennis Lundberg

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


Mime
View raw message