incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
Date Tue, 21 Aug 2012 14:53:14 GMT
On 21 August 2012 14:38, Benson Margulies <> wrote:
> On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir <> wrote:
>> On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz <> 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:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message