Hi Stephan, all,
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 know that there were some issue regarding QA'ing buildbot builds in
past. To get an idea what the real problem is, we should collect those
issues in detail when they occur to find the root cause for them (as we
always do). If those issues still are existent, I would await that this
list is already available somewhere (Mechtilde, do you have such list?).
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.
Really, we should investigate into the concrete list of issues before
thinking about any additional infrastructure. So if such list of issues
is available, I will ask someone of my team to take a look on it.
Nils
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
