incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [PROPOSAL] Starting the graduation process
Date Wed, 30 May 2012 00:18:23 GMT
On 30 May 2012 00:50, Rob Weir <> wrote:
> On Tue, May 29, 2012 at 7:34 PM, sebb <> wrote:
>> On 30 May 2012 00:03, Pedro Giffuni <> wrote:
>>> --- Mar 29/5/12, Rob Weir <> 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.

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

> 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?

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

> -Rob
>> [1]
>>> rhino --> Google V8
>>> nss   --> openssl
>>> Seamonkey --> Mulberry library
>>> but that doesn't seem to be a priority for 4.0 :( .
>>> Pedro.

View raw message