incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: [Code] strategy for "child works spaces"
Date Fri, 18 Nov 2011 18:26:46 GMT
Hi Eric;

--- On Fri, 11/18/11, eric b <> wrote:

> Disclaimer:  this list is not
> easy to read, and if the topic was already discussed. In
> this case, thanks in advance to provide me the right link
> :-)
> Hi,
> I perfectly know the importance of the IP clearance, but in
> parallel, we'll need to work on the code, say "partialy"
> (e.g. vcl + sd + slideshow only). In OOo we used child work
> spaces in that purpose, but I'm not sure we defined
> something similar yet with Apache

I personally don't understand well how those CWSs worked
or how they are integrated. I would personally prefer if
just use SVN branches exclusively from now on.

I think OOo has not really used this historically, but in
other projects developers have their own branches and can
do work without disrupting the main tree.

> Obviously, some parts of the IP clearance could be achieved
> this way too.

As I see things the absolute priority is to go through the
IP clearance process and before that nothing significant
will be integrated.

The big question is how much will we do between the IP
clearance and 3.4. There are a few CWSs that could be
integrated (mst had proposed a few) and I would
particularly favor gnumake4 as that would be in the
direction of getting rid of dmake which we will have
to do sooner or later.

I think for practical reasons, once the IP clearance
is done we will replace a few of the features with "free"
components and after that we will just do the release but
any feature or even bug fixes will be left for after 3.4.

This means 3.4 will have some very outdated components.
I am particularly concerned about ICU, but I already
made up to the idea it is unavoidable.

Right now I think the road ahead is as follows:

- Continue with IP clearance only (I estimate 2-3 weeks
but it's only a guess).
- Once that is over we have to discuss what features
can be recovered:
1) the COIN solver.
2) Update the wpdlib support?
3) Perhaps put back MySpell in addition to Hunspell.
4) Maybe update some non-critical components (ICC?).
- We branch 3.4 and only do finishing touches there.
  trunk can start doing aggressive CWSs merging,
  cleanups, new features, etc.

This surely requires more discussion and thinking, but
that's about all the planning I have in mind ATM.


> Thus, my questions are :
> - what is the current strategy ?
> - how does it work with svn ?  And if there is
> something existing, is the "methodology" available on the
> wiki ?
> To contribute to the debate, I'd suggest several
> mnimalistic rules :
> Methodology :
> 1. when starting working on a feature, an improvement or
> whatever, create an issue, as "reference" : ( )
> 2. inform the ooo-dev list with a subject like : [topic]
> working at something
> 3. if possible, try to describe the work in progress, on a
> wiki page. Sort of a draft, containing the story, and/or
> whatever helpfull for the developers.
> 4. (crazy idea) : do an "IRC ClassRoom" around the topic ?
> (questions, ideas, where / what in the code and so on,
> brainstorming, and keep the log)
> Some examples from OOo4Kids wiki (to show the principle
> with the wiki):
> - How cursors work in
> - Password protected preferences :
> - Math sources description :
> As you can see, the point is not to write stupid
> administrative specs, but to accompany the feature
> implementation, and invite to ask questions (and answr them
> if possible). Plus share the knowledge, of course.
> To improve the commit system :
> 5. before to commit, the commiter must build and verify the
> change will not introduce a build breaker. Else, inform and
> ask for a review on the ooo-dev list, in case of doubts.
> Thanks in advance,
> Eric Bachard
> --qɔᴉɹə
> Projet OOo4Kids :
> L'association EducOOo :
> Blog :

View raw message