incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <>
Subject Re: [Repo][Proposal]After the code is checked in to SVN
Date Sun, 21 Aug 2011 17:43:31 GMT
Hi Rob,

your plan makes sense to me. I would like to make some small changes.

On 21.08.2011 18:48, Rob Weir wrote:

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

Yes, the start for everything else should be a "perfect copy" of the hg
version. That will make it much easier to bring in more stuff from the
existing hg repos.

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

If the starting point is a "perfect copy", we can assume that it will
build if the build instructions of the OOo wiki are used (as this source
code version has been built successfully on all platforms already).

The next step should be to become "legally clean" as far as we can see.
That means, we should still be able to build OOo witout whatever we have
to remove or replace. The earlier we get rid of what we can't use in a
release, the better, as it helps estimating the amount of work to do.

As there is a lot to do, we need to coordinate. If we had an issue
tracker, we could submit tasks an let people assign themselves to the
tasks. But for the time being we have to do it differently.

As Eike and I already successfully made a Linux build without most of
the external copy-left components, we should get these patches in early.
Then we can work on my task list in the OOo wiki and perhaps some more
tasks we will find on our way through the code.

> 6) Then I think we can open it up to integrating CWS's, fixing bugs, etc.

We should integrate only those cws that have been created to become part
of OOo 3.4. tells me 12 candidates:
svg101, os152, calc69, tkr41, tkr40, sw34bf06, ooo340fixes, native373,
mba34issues01, fs34c, calc68, automationooo340m0. Only candidates, not more.

Other cws haven't been planned to become part of the OOO3.4 release and
I don't see a reason to change this plan.


View raw message