Re: [Libreoffice] [libreoffice-l10n] Re: REMINDER: Release 3.4.0-rc1 from ooo-build-3-2-1 branch == string and UI freeze

Le 03/05/11 12:30, Michael Meeks a écrit :

Hi Michael,

>       Which sucks; hopefully the Windows & Mac builds have been use-able for
> testing - and of course, the snapshots of them.

Unfortunately, both beta1 and beta2 refused to start on my Mac, that
kind of leaves potential volunteer testers with a bitter taste in their
mouth that their time could be better spent elsewhere despite their
willingness to help out <grin>.


As to using the nightly builds, well, I would say fine, if, and only if:

(a) they are actually available - speaking for Mac, this has not been a
regular occurrence for a while ;

(b) you can easily install it next to your production version of LO,
without it destroying your "stable" environment.

Of course, on Mac, the solution is relatively simple, but it still
involves :

(a) renaming your stable app bundle name to something other than the
string "LibreOffice" ;

(b) renaming your /Library/Applications Support/LibreOffice folder to
the same string as your newly renamed stable app ;

(c) installing the test version (be it beta, rc, or nightly).


That is a lot of effort for people who are keen to help out by just
testing to see if the app actually works !! Then they have to run the
battery of tests (still to be defined), and/or pick their favourite
module to test on, etc. Knowing that any extensions they might want to
test (other than bundled) also have to be reinstalled each time they
install a new test version, it makes for a rather painstaking testbed
setup. Hence, all the hooha about re-activating the "dev" switch so that
at least the testers can install a version of LibO which, in theory,
will be an independent, self-contained launchable version.

Personally, I get by with a mix of nightly build (when available) and
the betas, rcs, etc as and when they are released. However, I would like
to point out that currently, testing of nightly builds and reporting of
incidents related thereto seems to bear less weight with the devs than
the betas or rcs, probably because if it is reported on the dev mailing
list, then it can go unnoticed in the flow of patches flying back and
forwards (which would seem fairly logical). My current understanding is
that the QA Litmus framework is not yet quite ready for "prime time", so
in the meantime we still need a mechanism whereby anything we discover
in the nightly builds does not remain under the radar.

Bugzilla obviously doesn't appear to cater for such an eventuality as
yet. The question will also arise when testing nightly/daily builds as
to which branch of the repo actually represents the build - my
understanding is that the nightly/daily is from master - this is not the
same as the feature/string frozen branch of a future release, even if
the changes/bug fixes are pushed back to master afterwards. Master
potentially contains all sorts of stuff that will not be in the future
final release branch, or have I misunderstood something ?



Alex