incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Getting to our first build
Date Tue, 28 Jun 2011 17:39:09 GMT
On Tue, Jun 28, 2011 at 12:59, Rob Weir <apache@robweir.com> wrote:
> On Tue, Jun 28, 2011 at 12:35 PM, Mathias Bauer <Mathias_Bauer@gmx.net> wrote:
>...
>> So let me try to summarize:
>>
>> We take the OOo source code with tag OOO340_m1 from
>> hg.services.openoffice.org, 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.

Yup.

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

We need to get all of the content from Hg that we would like. Merged
into one fat repository. Convert that thing to a Subversion
repository. Then we 'svnadmin dump' the repository, and pass the
resulting dumpfile to the Infrastructure team. They will schedule a
"Subversion is read-only" period, probably on a weekend. They will
then use 'svnadmin load' to haul all the revisions into the Apache
repository. This is the most efficient mechanism, it will avoid people
committing during the load (creating potential burps in the revision
sequence for OOo), and it will avoid sending commit messages.

Again, please refer to:
  http://cmpilato.blogspot.com/2009/11/revisionist-history.html

I believe we want to pull all the bits together in a repeatable and
documented fashion before handing the dumpfile over to Infrastructure
for loading.

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

Yes. These notices go into trunk/NOTICE, per the instructions of ALv2.

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

Yup.

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

This is correct (both Mathias and Rob).

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

Fully agreed.

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

We should strive very hard to make a *single* request from Oracle. Any
request involves the time/efforts/cost of their Legal team. In
fairness to them, we should attempt to limit our demand of their time.

Cheers,
-g

Mime
View raw message