Re: [Libreoffice] minutes of tech steering call ...

On Fri, 2011-06-24 at 19:21 -0500, Norbert Thiebaud wrote:
> As caolan said in another post, 'master' should no be seen as
> 'unstable'. 'master' should be seen as the latest version about to be
> released... Sure there will be time when master breaks... but that
> should be rare and short-lived. 

There is also the need to distinguish between the *build* breaking and
the code/binaries themselves being broken. The first is mostly a
developer annoyance, though causes delays in getting dailies available
for a platform and delays in development, but ultimately not having an
effect on the quality of the product itself. The second is the real
problem.

Detecting problems early at the developer side, e.g. right at the moment
they cock it up rather than later on when its available for qa, is a
good thing. On that side of stuff we have currently...

a) the smoketest which is automatically run now (on Linux and Mac) when
a development does a make dev-install, so if the thing builds at all, it
should be fairly guaranteed to be capable of basic use
b) a pile of run-at-build-time unit tests which exercise things like
.rtf import, .doc import, .xls import and other more obscure items.
Again those should make it nigh impossible for a dev to break those
fundamentally.
c) the "make check" heavy weight subsequent checks automation, which is
in need of some love in e.g. forms, and an updated test or two in sw,
etc. That needs more work at the moment, though it did already find a
problem in the binaryurp rework.

b already IMO proved itself by e.g. finding early the potential cockups
in the calc mdds work on windows, some obscure i18n text categorization
stuff, the fascinating difference in some threading issues between
windows and linux etc, some otherwise undetected merge problems in
the .doc import etc. And, almost be definition, the only ones in the b
category that anyone other than the originating developer gets to hear
about are the different-platform ones. This is the right way in general
for devs to go IMO, fix a bug and add a test to make sure it stays
fixed. The gcc guys test-suite is a good example here.

Hopefully the goal should be that what qa end up looking at are the
"human" level things, stuff that doesn't work the way it's advertised,
and GUI interactions that are hard to capture with unit tests.

C.