Stephan Bergmann wrote:
> On Aug 21, 2011, at 6:48 PM, Rob Weir wrote:
>> 1) Initially, only changes are made to make SVN to more perfectly
>> match the Hg tip. We know there are 10 or so files that need to be
>> checked in, with attention to EOL style. And there was a suggestion
>> to update the memo of the initial checkin. Let's get that work done,
>> and then tag that revision with a memorable label, before we make any
>> other changes. (Should also give a tag to the current Hg tip)
>>
>> 2) Registration of any cryptographic code in OOo (required for US
>> Export regulations, not sure if this was previously required when OOo
>> was hosted in Germany).
>>
>> 3) Then do what is necessary to enable anyone who wishes to build to
>> do so. So confirm we can build, add files, etc., if they are missing.
>> Get instructions onto the website, or links to instructions.
>> Everything we do after this is easier if we first enable more people
>> to work with the code. Obviously a newbie is not going to be
>> productive on their first day, but the sooner we get them working with
>> the code, the sooner they will be productive. I think we should try
>> to enable that now, than wait 6 months.
>>
>> 4) As part of verifying the build we should be able to confirm what
>> additional files, if any we need to request that Oracle add to their
>> SGA.
>>
>> 5) Identification and removal of any code that does not have a
>> compatible license
>>
>> 6) Then I think we can open it up to integrating CWS's, fixing bugs, etc.
>
> Two more steps that we might want to phase in somewhere are:
>
> (a) Replace the Oracle/LGPLv3 license headers in all the relevant files with Apache/AL2
ones. Is this maybe legally important to do as early as possible, or can it wait until end-of-incubation?
Probably makes no sense to do before phase 5, anyway.
Required to graduate from incubator, the sooner the better. IP clean up
is discussed quite often in the general@i.a.o list.
> (b) Optionally, do some automated cleanup. For example, LibreOffice recently did some
automated whitespace and tab cleanup when merging their spread git repos into a single big
one. Such cleanup is probably a good idea (if only to follow LOs example and not let the
two code bases diverge more than necessary), but generally it of course complicates merging
of existing changesets, so a time of "starting fresh" can be a good time for such a change
(which implies that it would probably best be done after integrating the changesets from existing
CWS in phase 6).
>
> -Stephan
|