Hi,
another problem or rather a question is: what are Buildbots meant to be
good for?
Fom when they were introduced they had two tasks to perform
1. Test the build under as many different system configurations as possible.
2. Produce builds which are suitable for QA.
so the Buildbots seem to rather obey rule #1 now.
The question is if we want to neglect this task of the bots in favor of
#2 or not.
Gregor
Stephan Bergmann schrieb:
During FOSDEM, Mechtilde told me about a problem the QA community is
experiencing, namely that buildbot builds (of CWSs) are quite different
functionality-wise from the standard builds (of milestones and releases,
often done by Sun Hamburg Release Engineering). Those differences are
especially apparent in Base, Mechtilde told me. This problem in some
cases prevents easy testing of a CWS by the QA community, or even
thorough testing of a CWS in real life by replacing a standard OOo build
with a buildbot CWS build in (semi-)production use.
I would assume there are three factors that cause the variance in
functionality. For one, Sun Hamburg uses a setsolar build environment
instead of the configure build environment used by everybody else (incl.
buildbots); what the configure switches corresponding to the setsolar
build environment would look like is more or less directly codified in
ooo/trunk/solenv/config/sdev300.ini. For another, even if Sun Hamburg
used a configure build environment, I assume that many buildbots use
additional configure switches that influence the functionality of the
resulting OOo. Like when there is a problem building OOo on a given
buildbot, and that problem can be worked around with some configure
switch, that switch is simply used. That way, I would not be surprised
if different buildbots even used different sets of configure switches.
(I do not know where to easily look up which buildbot uses which
switches, so I did not bother to check.)
A third factor might be that different build machines have different
versions of compilers and linkers installed, and different versions of
header files that OOo code includes or different versions of system
libraries that OOo code links against. (By the way, the Sun Hamburg
setsolar environment almost completely hides this by providing a
centrally managed baseline build environment independent of the machine
one is building on.) I would assume that this has much less influence
on the observed variance than the configure switches, however.
So, in an ideal world, for all the important platforms for which we
provide standard builds we should also provide buildbots that produce
builds that are (close to) identical functionality-wise to the standard
ones. I would love to see someone pick up on this, presumably from the
Sun Hamburg infrastructure group. Niels? Anybody? As I understood
Mechtilde, she would be happy to help in QAing the processes of getting
the buidbots in shape, like testing whether the resulting builds are
good enough for practical purposes.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
--
Sun Microsystems GmbH Gregor Hartmann
Nagelsweg 55
D-20097 Hamburg Phone: (+49 40)23646 892
http://www.sun.de mailto:gregor.hartm...@sun.com
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
