incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Bergmann <>
Subject Re: [Repo][Proposal]After the code is checked in to SVN
Date Tue, 23 Aug 2011 11:07:16 GMT
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.

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

View raw message