Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of rgardler@opendirective.com
 designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FC8826B.2090600@googlemail.com>
References: <1338428718.42092.YahooMailClassic@web113506.mail.gq1.yahoo.com>
 <4FC75BEA.1070808@a-w-f.de>
 <CAKQbXgB3Rs4UJ2=BVbU8BdR4kED671=WSViO2VeM1pxccJ9udQ@mail.gmail.com>
 <4FC790BE.3050008@googlemail.com> <4FC79BA7.1060707@apache.org>
 <CAKQbXgCXRVHLVe3rrOPp0NZLD-aitQ6XQk+jtrAjzfW-RLtF6g@mail.gmail.com>
 <4FC8826B.2090600@googlemail.com>
From: Ross Gardler <rgardler@opendirective.com>
Date: Fri, 1 Jun 2012 10:07:39 +0100
Message-ID: 
 <CAKQbXgBcZ96LP273Q6E1SD2GpMDQDLCzAhrg3erp5YA3NbbMAw@mail.gmail.com>
Subject: Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the
 graduation process)
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 1 June 2012 09:50, J=FCrgen Schmidt <jogischmidt@googlemail.com> wrote:
> On 6/1/12 9:47 AM, Ross Gardler wrote:
>> Sent from my mobile device, please forgive errors and brevity.
>> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pfg@apache.org> wrote:
>>>

...

>>> I admit this is very clear. I don't expect such development to be
>>> a requirement for graduation but the transitory situation of a source
>>> release that depends on carrying category-B tarballs in SVN now is
>>> not really acceptable.
>>
>> I do expect this to be sorted out before graduation.
>
> it is addressed already
>
>> That might be as simple as getting clarity on the policy, it might be mo=
re
>> than that. However, as a mentor I am uncertain about the practice adopte=
d
>> here and as such will not encourage the IPMC to vote for graduation unti=
l
>> someone in the PPMC gets clarity.
>
> what do you expect?

Someone needs to take out all the rhetoric and abstract concepts. Pick
any one of the cat-b cases and describe *exactly* how it is addressed
in that case and *exactly* how this conforms to documented ASF
policies.

Once we have clarity on the first case we can ask whether any of the
other cases are different and then examine those.

> Should we remove all this dependencies and make AOO more or less
> unusable or better uninteresting for real usage?

I am making no comment on what the technical solution is.

I want to see consensus. Consensus cannot be gained by shouting at one
another about vague examples. I want concrete examples on a case by
case basis until nobody is objecting or until the issues can be
clearly communicated to either the IPMC or legal@ so that a
clarification of ASF policy can be made.

> Anyway I think we tried everything to address this and we still work on
> improvements step by step. If that is not enough for graduation I would
> feel very unsatisfied.

It is, and always has been, a condition of graduation that the IP
situation in the project conforms to ASF policies. There is a question
about these tarballs and it must be resolved before graduation.

Ross