incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 08:50:51 GMT
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:
>>
>> Hi Jürgen;
>>
>> Let me clarify some issues too ...
>>
>> On 05/31/12 10:39, Jürgen Schmidt wrote:
>>>
>>> ...
>>>
> 
> ...
> 
>>
>>> 6. we agreed to upstream changes to external libs where possible and
>>> necessary. And we agreed to improve the workflow to use the tar-balls
>>> from their original source where possible over time and where we can
>>> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>>>
>> Yes. Most of them are just uninteresting upstream.
> 
> This is the part that really bothers me. There is a world of difference
> between providing unmodified cat-b sources and providing modified cat-b
> sources. The ASF only releases software under the ALv2. If any of these
> cat-b sources have modifications they cannot, IMHO, be managed by the ASF
> unless specific approval for an exception to policy is sought.
> 

with my statement above I didn't differentiate between cat-a or cat-b
etc. The general approach is
- that we try to upstream patches where possible.
- we often apply patches to make the source compilable in our build env.
The reason why this is necessary is much more complex.

> If there are no modifications the position is much less clear, but still
> needs examination.
> 
>> 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 more
> than that. However, as a mentor I am uncertain about the practice adopted
> here and as such will not encourage the IPMC to vote for graduation until
> someone in the PPMC gets clarity.

what do you expect?

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

Mmm, maybe a good idea. We would get rid of the binary releases because
nobody would be interested in them. But who would build and provide
binaries? Do you think we could attract any new developer to work on AOO
in this case?

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. We can't perform magic and we think more
practical according the Apache rules/policies as we understand them.


Juergen


> 
> As a mentor I'm not going to do it. I've been asked to stop doing stuff for
> the community and let it manage its own afairs, and I'm happy to do so.
> 
> Ross
> 


Mime
View raw message