incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [PROPOSAL] Starting the graduation process
Date Wed, 30 May 2012 00:43:20 GMT
On Tue, May 29, 2012 at 8:18 PM, sebb <sebbaz@gmail.com> wrote:
> On 30 May 2012 00:50, Rob Weir <robweir@apache.org> wrote:
>> On Tue, May 29, 2012 at 7:34 PM, sebb <sebbaz@gmail.com> wrote:
>>> On 30 May 2012 00:03, Pedro Giffuni <pfg@apache.org> wrote:
>>>>
>>>> --- Mar 29/5/12, Rob Weir <robweir@apache.org> ha scritto:
>>>> ...
>>>>
>>>>> >
>>>>> > The idea that we have remaining issues with Category-B
>>>>> > tarballs in the tree has been around since before the
>>>>> > release, and one of our mentors (Ross I recall) did
>>>>> > acknowledge my point of view.
>>>>> >
>>>>>
>>>>> Again, I don't see an issue here.  But if you feel
>>>>> strongly about this you are welcome to copy the
>>>>> ext_sources over to Apache Extras and do a
>>>>> trivial update of the build
>>>>> script.   Whatever makes you happy.
>>>>
>>>> I am busy at the moment, plus doing this will
>>>> mean I have to suspend the updates I was working
>>>> on.
>>>>
>>>> I think I will start next week. I will only move
>>>> Category-B code and I will disable it from the
>>>> buildbots too: it's rather inconvenient to have
>>>> the buildbot depend on downloading extra tarballs.
>>>>
>>>> This is admittedly a stop gap solution to comply
>>>> better with the Apache policies, the real fix would
>>>> be to work collectively on replacing the code that
>>>> can be replaced:
>>>
>>> Alternatively, it is possible to include cat B [1] dependencies in binary form.
>>> Is there any need to include the source?
>>>
>>
>> If the build did not consumer source then we would need to store, in
>> SVN,  category-b binaries files for each component, in each
>> platform/architecture.  That would be 4 platforms now, but I'd expect
>> that go up to 7 in the near future.
>
> Surely at least Mozilla Rhino is written in Java, and tar balls are
> published in various locations (e.g. Maven Central) suitable for use
> as part of a build.
>

Maven is a good analogy.  We've essentially reinvented Maven, only we
did it before Maven did.  Although you could argue for Maven for Java
dependencies, I'd rather use a single mechanism for all dependencies
rather than multiple ones.

> If there are other non-Java dependencies that are not available for
> all platforms as binaries, then of course the source needs to be
> built.
>

Thus what we have.

>> I don't think that solves any real problem.  We'd still need access to
>> the source to provide urgent security patches, etc.  So we're then
>> back to the same question:  where to store the category-b source
>> tarballs?
>
> If the dependency is provided as a binary by the maintainer, then
> surely it is up to them to apply patches and provide patched builds?
>

In almost all cases the binaries are not provided by the maintainer on
the full range of platforms that we support.

> Likewise, surely security fixes will be applied by the maintainers to
> their source?
>

To source, but not always to binaries, since they don't typically
provide binaries.  And not always to older versions of the source
distributions.  We might be using version N-1 of a component and
cannot quickly consume  version N of a component in order to meet the
urgency of a security fix.  So we could need to backport a security
patch.

In any case, this as all been discussed previously, and the various
options have been explored.  Surely this is for the project to figure
out?  If something was truly a question of policy and an important
Foundation principle was at stake, it would not vary according to the
underlying technology and we would not be discussing the
implementation details.  If it was a policy issue then we'd be
discussing policy and the principles behind the policy.

As you know the licensing policy is based on three very simple
principles [1].    Do you have any concerns with our meeting these
principles?   We can discuss configuration management, but the
principles at stake are not technological.  They are about the
obligations of downstream source consumers and whether we give them
ample warning and notification about what these obligations are.

[1] http://www.apache.org/legal/resolved.html#criteria

>> -Rob
>>
>>> [1] http://www.apache.org/legal/resolved.html#category-b
>>>
>>>> rhino --> Google V8
>>>> nss   --> openssl
>>>> Seamonkey --> Mulberry library
>>>>
>>>> but that doesn't seem to be a priority for 4.0 :( .
>>>>
>>>> Pedro.
>>>>

Mime
View raw message