incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Rist <andrew.r...@oracle.com>
Subject Re: Getting to our first build
Date Wed, 29 Jun 2011 21:59:51 GMT
+1

( I realize I'm several messages behind here, but after a couple of days 
OOTO I've been doing the Sisyphean task working my way up the mountain 
of ooo-dev messages)



On 6/28/2011 9:59 AM, Rob Weir wrote:
> On Tue, Jun 28, 2011 at 12:35 PM, Mathias Bauer<Mathias_Bauer@gmx.net>  wrote:
>> On 28.06.2011 18:05, Greg Stein wrote:
>>> On Tue, Jun 28, 2011 at 07:34, Rob Weir<apache@robweir.com>    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
>> 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.
>>
> 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
> forward.
>
> 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.
>
> -Rob
>
>
>> Is that correct?
>>
>> Regards,
>> Mathias
>>
>>
>>
>>> Cheers,
>>> -g
>>>
>>

Mime
View raw message