On 21 August 2012 14:38, Benson Margulies <bimargul...@gmail.com> wrote:
> On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir <robw...@apache.org> wrote:
>> On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz <twgo...@gmx.de> wrote:
>>> On 21/08/12 13:59, Branko Čibej wrote:
>>>> On 21.08.2012 12:52, sebb wrote:
>>>>> I think the NOTICE problems are serious enough to warrant a respin.
>>>>
>>>> This is an unreasonable request. The IPMC voted on the 3.4.0 release.
>>>> The notice file has not changed between 3.4.0 and 3.4.1. How then do you
>>>> justify this new requirement?
>>>
>>> Let me offer some advice from somebody who has been where you
>>> are now.  Please keep in mind that the ASF is a large, volunteer
>>> organization.  The backs and forths you are seeing here are
>>> normal and probably can't be avoided in flat organization like
>>> this.  This can be strange and/or frustrating to people who are
>>> either paid to do their Apache work, or who come from smaller
>>> organizations where it was easier to come to a decision.  Try
>>> to keep a positive attitude, go with the flow, and become a part
>>> of the wider Apache community (not just your project).  Help
>>> improve things where you see they are lacking.  This community
>>> aspect is very important at Apache.
>>>
>>> As to the issue at hand, this is not a new requirement.  The
>>> issue just wasn't spotted last time.  Yes, that's annoying, but
>>> it can't be helped.  The NOTICE and the LICENSE files are the
>>> most important files in your distribution, and you should make
>>> every effort to get them right.  Sebb raises valid concerns that
>>> need to be addressed.
>
> this point has, in fact, been the subject of a long-standing debate in
> the IPMC. While I have the greatest respect for sebb, there are other
> members of this PMC for whom I also have great respect who have taken
> the opposite view -- that - within reason - flaws in these files can
> be noted and repaired for the next release.

There are two issues here:
1) whether the NOTICE file is correct
2) if not, whether the problems are such as to require a respin.

I hope we are agreed that the NOTICE file is not correct.

The reason I think that problems in NOTICE files are to be taken
seriously is that the N (&L) files are vital for our licensing.

> The situation at hand is complicated by the running graduation thread
> for AOO, since it seems to me to be reasonable to expect that these
> files have achieved a consensus state before graduation. However,
> that's just a thought on my part.
>
>
>
>
>>>
>>
>> A suggested exercise at ApacheCon.  Get a group of 20 Members, break
>> them into groups of 5.  Give each group an identical list of 3rd party
>> dependencies and ask them to create a NOTICE file that expresses them.
>>  Give them 30 minutes.  Compare the results.
>>
>> I'd bet any amount that all four NOTICE files will differ in
>> substantive ways, and that there would be disagreement, both within
>> the groups, and across the groups, on which was "correct".
>>
>> -Rob
>>
>>> Just trying to help here, so no flak my way please :-)
>>>
>>> BTW, I think AOO is doing an amazing job.  I was not optimistic
>>> when the project came to Apache, and I'm amazed you are where
>>> you are now.  Keep up the good work.
>>>
>>> --Thilo
>>>
>>>
>>>>
>>>> It is not fair to the podling if the IPMC invents new requirements and
>>>> reverses its own decisions for no apparent reason. This NOTICE issue
>>>> certainly shouldn't be ground for vetoing a release.
>>>>
>>>> By the way, the same holds for binaries being included in the releases.
>>>> The 3.4.0 release, with binaries, was approved. If the podling did not
>>>> change its release procedures and policies and artefacts in the
>>>> meantime, it's not reasonable to hold up what amounts to a security
>>>> release solely based on the IPMC having screwed up the previous release
>>>> vote.
>>>>
>>>> It is fair to require changes for the next release. It's not fair to use
>>>> different criteria for two successive, essentially identical releases.
>>>> (N.B.: I use the term "essentially identical" in the sense that, whilst
>>>> some of the sources have changed, the overall structure of the release
>>>> artefacts has not.)
>>>>
>>>> -- Brane
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to