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 [email protected] 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
