openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: [Repo][Proposal]After the code is checked in to SVN
Date Sun, 21 Aug 2011 17:25:20 GMT
Am 08/21/2011 06:48 PM, schrieb Rob Weir:
> Soon, I hope, the OOo code will be checked into SVN.  After that
> happens I think we need to coordinate on the next steps.  I know that
> several of us have code they'd like to check-in, CWS's to integrate,
> LGPL code to remove, etc.  But let's stage this work carefully, so we
> minimize problems.
>
> Could we do something like this:
>
> 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)

+1

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

OOo was already hosted in the US, so IMHO need for any additional things.

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

+1

 > 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.
>
>
> Does this make sense?  I'm open to variations on this, but I think we
> need to stage the work somewhat like the above.

If we cannot do AOO 3.4 as a kind of exceptional release then we have to 
do 5) before the release.

Furthermore, we really have to think when exactly we need to branch, so 
that we have the first branch for a AOO 3.4 release and the endless 
trunk "branch". IMHO we should do it at latest before 6).

Please don't put everything new into the same branch!

We had OOo 3.4 already in Beta mode and I don't recommend to open up 
this again for our first release. We should finish the work for the 
nearly finished codeline, learn how the things are working and take this 
into account when preparing for the next release.

My 2 ct as non-coder.

Marcus


Mime
View raw message