incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Getting to our first build
Date Tue, 28 Jun 2011 17:22:32 GMT
Hi Rob,

On Jun 28, 2011, at 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.

This is good. If the question of provenance ever comes up, by having the files in SVN, removed
and then replaced we have clear evidence instead of the absence of evidence.


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

I think that this is a good plan.

Once we have a stable build we should make use of Continuous Integration - http://ci.apache.org/

The buildbot that is used for CMS is one example. I think that Hudson is being replaced by
Jenkins.

Regards,
Dave



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


Mime
View raw message