Development infrastructure and methodology for OO

[Benson Margulies <bi...@gmail.com>]

Here is a thread for some infrastructure implications of an OO podling.

Things to note:

1. OO is very large.

2. OO is a good-old C++ giant. It's not 'build once, run anywhere'. It
has to be built many times in many configurations to maintain
regression testing.

There is, in short, a detectable dollar cost in build machines to run
all the builds needed to keep up with it.


3. OO has a well-establish development methodology which will be new
and interesting at Apache. It is a very branch-intensive methodology,
involving these CWS things.

This, I think, is the root of the 'oh, no, svn' traffic. I've never
seen extensive bi-directional merging work well in svn. If there was
ever a job for a dvcs ...

Perhaps, this can work by allowing the not-cooked-yet versions to be
outboard in git, and coming up with a scheme to document provenance as
they merge into svn. Perhaps not. Perhaps this really should be
considered as a test case for the rw-git infrastructure that is under
construction. But I don't think that it can be dismissed with a wave
of the hand and a flat statement of 'svn works for everyone else at
Apache.'

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Development infrastructure and methodology for OO

[Christian Lippka <cl...@lippka.com>]

Am 03.06.2011 14:52, schrieb Benson Margulies:
> Here is a thread for some infrastructure implications of an OO podling.
>
> Things to note:
>
> 1. OO is very large.
>
> 2. OO is a good-old C++ giant. It's not 'build once, run anywhere'. It
> has to be built many times in many configurations to maintain
> regression testing.
>
> There is, in short, a detectable dollar cost in build machines to run
> all the builds needed to keep up with it.
Yes, build machines are something that is needed, since not all 
developers have
two linux flavors, a windows and a mac system available at all times. 
Fortunately,
the software to do automated builds on dedicated machines connected to 
the web
is already available.

> 3. OO has a well-establish development methodology which will be new
> and interesting at Apache. It is a very branch-intensive methodology,
> involving these CWS things.
>
> This, I think, is the root of the 'oh, no, svn' traffic. I've never
> seen extensive bi-directional merging work well in svn. If there was
> ever a job for a dvcs ...
While personally I favor the CWS thingy, there are other opinions on 
this. So this
may be a process that needs to be re evaluated.

What I'm currently thinking about is a model using both svn and a dvcs 
in the
short term. Having development of medium to large code changes take place
in self hosted git or mercurial repositories. Providing an 
infrastructure of build
machines so that interested and QA community members can request builds
to check out work in progress stuff. If the work is deemed to be stable 
enough
for the master it could be transfered from the dvcs to svn. IMHO, this is a
practice that Novel used for the go-oo fork before OpenOffice.org 
switched to
Mercurial.

Regards,
Christian

Disclaimer: These are my opinions as an individual interested in the 
future of an open source office suite. I do not speak for my current 
employer.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org