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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
