openoffice-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 22:05:12 GMT
Hi Eric;

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

> > 
> > I personally don't understand well how those CWSs
> worked or how they are integrated.
> One released version of 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

That's the main thing VCSs do. But what I read
CWS started in CVS and were adapted to work similarly
in SVN and Hg. 
If I download a CWS, will I get a diff or a code tree?

The nice thing in SVN you can merge from the current
code and you can keep in line with the upstream code.

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

We usually do it the other way around: you first merge
current (trunk) into you branch, test it well, and then
merge it back upstream.

I still have some more reading to do in the SVN handbook
but I have the impression that you guys reinvented the
wheel all along :).

Not that anything is too easy: FreeBSD used CVS and
perforce for a long while before deciding to move to
SVN and some people like git too.
> 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.

Thanks, this is a summary of how this has worked for

so I expect this is basically the same issue, but at a
different level.

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

This is never easy but SVN does help: it knows when files have
moved or if some simple changes still apply.
> > 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.

IP clearance is one a life time thing and it's the great
bottleneck for a release at this point. I think the wiki
+bugzilla works well enough for now.

The problem is that Wiki+bugzilla is not a sustainable
development model for what follows.

> I'm not sure to I agree:  introduce gnumake4 will
> introduce a lot of issues build breakers and more. 

OK, I was under the impression that gnumake4 was
actually small but I can live without more
stuff being integrated.

> That's why I'd prefer build using an old but working well
> tool and introduce build breakers later.

OK. I do think after 3.4 we should integrate everything from
Oracle that makes sense.

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

hmm .. We are not really breaking things but we are cutting
things from the build. Some changes are really nice: OOo is
very bloated and getting rid of some of the GNU stuff like
regex and glibc makes sense and a lot of stuff is not really
used at all.
> 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:

I forgot: we have to run flawfinder, a security audit
tool that produces lots of false positives but that
nevertheless sometimes detects some hazards.
> 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.

Yes we have to document well the requirements and the build
steps. I personally use two flavors of scripts for my test

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

Are we really too bad on those? The main boring issues
for me have always been:

1) OOo is too slow to get up running.
2) The compatibility with MS-Office is not too good: margins
don't match, colors look different.

but those are not going to be fixed in 3.4.

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

Yes, I'll read more about SVN and branching.


View raw message