incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric b <eric.bach...@free.fr>
Subject Re: [Code] strategy for "child works spaces"
Date Fri, 18 Nov 2011 20:29:49 GMT
Hi Pedro,

Le 18 nov. 11 à 19:26, Pedro Giffuni a écrit :

> Hi Eric;
>
> --- On Fri, 11/18/11, eric b <eric.bachard@free.fr> 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 OpenOffice.org.
>>
>
> I personally don't understand well how those CWSs worked or how  
> they are integrated.


One released version of OpenOffice.org was named "a milestone".  
Between one milestone and the next one, we integrate several cws (the  
number may vary).

We could summarize :   milestone N  + several cws's == milestone N+1

More about one cws :

Formaly, this is a set of changes, based on a milestone. More  
precisely, a cws is a branch (not sure with the term) based on a  
milestone, defined during it's creation. The main idea is that the  
developer can commit changes without break HEAD. When the cws is  
confirmed ok ( e.g. the feature works, no breakage on any OS, and no  
known issue introduced and so on, the cws is ready for integration.  
At the end, was the release engineer who decided which cws's can be  
integrated, to define the next OpenOffice.org milestone.

The drawback is, that the dev must not take a too long time to add  
the new code: when enough of other cws's are ok, they can be  
integrateed, and new milestones appear in meantime. Waiting too long  
means the dev will have to resync the cws with a more recent  
milestone, because the diff will no longer apply.

FYI, one link who could help you.  http:// 
wiki.services.openoffice.org/wiki/ChildWorkSpace



> I would personally prefer if just use SVN branches exclusively from  
> now on.
>

I think SVN branches is similar, but since code is commited a bit  
randomly, there is no certitude the code is the same between the time  
I checkout and the time I want to commit my diff.  e.g. the part of  
the code I'm working on can be obsolete e.g. somebody modified the  
same files as the one I was working 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.

I think we are discussing about the same idea :-)



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


My proposal was to "organize" more the IP clearance.


> 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'm not sure to I agree:  introduce gnumake4 will introduce a lot of  
issues build breakers and more.  That's why I'd prefer build using an  
old but working well tool and introduce build breakers 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.
>


More IP clearance goes, and less I see something buildable, but 'm  
probably wrong.



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


Indeed ICU,  is a nice mess.  Worse: I bet a lot of the binaries we  
build are maybe completely useless since years, and help to provide a  
bloated set.


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


There is one important step (I didn't see it) :  we must provide  
robust and well working instructions to build OOo, everywhere,  
because what counts is the number of people building, and able to  
say : no problem, or there is one breaker.

I remember what did the MAc os X port success : lot of people  
building and building again.


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


More urgent : fix crashes, and boring (for the user) issues



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

Yes, sure : let's organize a bit.


Regards,
Eric

-- 
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message