incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Getting to our first build
Date Tue, 28 Jun 2011 16:59:25 GMT
On Tue, Jun 28, 2011 at 12:35 PM, Mathias Bauer <> wrote:
> On 28.06.2011 18:05, Greg Stein wrote:
>> On Tue, Jun 28, 2011 at 07:34, Rob Weir<>  wrote:
>>> ...
>>> Hi Mathias,
>>> I don't know whether my approach is feasible either.  I know we can
>>> set properties on files in SVN.  You can retrieve them individually,
>>> but I don't see a way to query them, e.g., list all files that don't
>>> have a license property, or download all files that have a license
>>> property set to Apache 2.0.
>> I'm not entirely sure about tagging like this. An interesting idea,
>> definitely.
>> In any case, you're right in terms of Subversion's query capabilities.
>> You can list properties of nodes, but you cannot form queries to
>> return nodes with certain property configurations.
>> I somewhat prefer managing the IP aspect with separate lists of files,
>> rather than injecting that information into the repository.
>>> So fa, I think that you've been doing most of the code investigations.
>>>  So I'd trust your judgement on what the next steps should be.  Do you
>>> have any thoughts what work remains for the next 1 or 2 weeks?  For
>>> example, is Oracle currently reviewing the additional SGA requesets?
>>> Or do we need to request this still?
>> Nobody has made a request. Nobody has produced a list of files to request.
>>> If I understand the rules at Apache (and it is certainly possible I
>>> have this wrong, but in that case Im sure someone will quickly correct
>>> me), a Podling can check in all of the code, including parts that are
>>> LGPL/GPL. We can make builds from that.  But we are not permitted to
>>> make a releases or to graduate from a podling until we have gone
>>> through the IP checklist, including dealing with code that has an
>>> incompatible license.
>> You have this entirely correct. Thanks!
>>> Of course, if you think you are close to having a "clean" version of
>>> OOo ready to check in, then I don't want to interrupt the fine work
>>> that you are already doing.  But in that case I think it would help if
>>> we had a "roadmap" for the next couple of weeks, of what tasks
>>> remains, so others can help as well.
>> I still believe that we would like *history* rather than simply
>> copying over "tip" from the old repository. Having that history in one
>> repository is so incredibly useful to so many people, that I cannot
>> see why we would skip it. It costs us pain *now*, but think about how
>> long this codebase will live? Will people a decade from now want to
>> use two repositories to investigate history?
> So let me try to summarize:
> We take the OOo source code with tag OOO340_m1 from
>, including the full history, means: we will just
> import it from hg to svn. Then we use the lists of "naughty" files I have
> created and remove the files with "svn remove" that may not stay in the
> Apache repository.

I see it like this:

1) Coordinate the check in so we can do it on the Apache server if
possible (to save time).  Also, we should disable the commit list
notification emails during the check in.  Otherwise we'll cause
everyone's email files to explode and catch on fire.

2) Check in the OOO340_m1 code, with history.

3) Verify that we can extract that source and build it.  I know that
sounds like a trivial thing, but I think we can use this to encourage
as many project members as possible to download the source, set up a
build environment and confirm that they can build.  Having many
committers with a working build environment will help us going

4) At this point the code will be a mix:

a) Oracle SGA-provided code.  No action needed on these.

b) 3rd party code with a compatible license.  We need a list of these
so we can provided proper notice in our releases, to respect the terms
of the license.

c) 3rd party code with an incompatible license.  We need to understand
these dependencies and agree on how to handle them.

d) Oracle code that was not included in the initial SGA.  We need to
ask Oracle to amend their SGA to include these files.

I think we can handle some of this in parallel.

> In result we will have some files with LGPL or MPL in our repository (in the
> history), but on "head" they will be removed. "head" will have only files
> that are owned by Oracle (and will get ASL from Oracle) and those files that
> are not owned by Oracle, but are part of the current OOo repository and have
> a license that is compatible with ASL.

This is correct for incompatible 3rd party licensed code.  We would
"svn delete" these.  But this does not need to be an immediate thing,
where we quickly delete all GPL code as quickly as possible.  We can
do it module by module, replacing pieces as we go.  The main
restriction is that we cannot do a podling release with the
incompatible code in it.  But we can spent a month or more, if needed,
working in the repository, doing developer builds, etc.

> Then we start to fix the build.

There are different opinions on this.  My preference is to never have
the build be broken.  Keep it always in buildable, runnable condition.
 Otherwise it is hard to expect that other project members will test
their code before checking it in.  If the build is broken it tends to
get even more broken very quickly.  I'd recommend that we clean up the
GPL dependencies library by library, always keeping the build working.
 Of course, that is in a perfect world.  But we should try to aim for
that, I think.

So in summary, I'm proposing that we check in the existing code, with
history, and verify that we can build it.  That establish a "stable
build".  Then work on the provenance review, making additional Oracle
requests and removing incompatible libraries as we go, but always
aiming to keep the build stable.


> Is that correct?
> Regards,
> Mathias
>> Cheers,
>> -g

View raw message