Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


Hi Thorsten, *,

Thorsten Behrens schrieb:

as we start to ramp up more infrastructure, I'd like to make
you think about what's crucially needed to do QA for LibreOffice
3.3.

First of all, this is what we currently have:

<stretched>

* a LibreOffice technical list (I'd like to have devs & QA
  discussion there):

So do I, but I'd suggest to put the patch conversation on a different
list - sort of patches@libreoffice.org.

* a bugtracker - bugs.freedesktop.org for the while (use

* a wiki (well, soon ;))

* the testtool (similar to OpenOffice.org)

</stretched>

+1

I'd prefer if we do the 3.3 release in a somewhat lightweight
fashion, and add tools as we go (and decide that we need them)

+1

I know that the OpenOffice.org QA project has things like QATrack,
QUASTe, and TCM - but I wonder which of those pass the test of "we
really need it, and it's worth the effort to duplicate it/set it up".

What do you think?

I'll put here a short draft of my dreams if I think of an efficient QA
:o))

I think of three states the software idally should pass:

1. The most recent developer build (nightly builds).

2. an "alive" release lets call it "LibO - fresh" which passed a quite
   short beta period for early adopters, experienced users, and "new
   features greedy" ones.

3. a "mature" release which has passed ~6 months "fresh" state.


First point doesn't need additional comments

2. comment:
"fresh" issues reported by "fresh"-users should get fixed as soon as
possible and end in nightly builds after an issue has been fixed.

3. comment:
"mature" issues can only be security issues and should also be aided by
nightly builds each time an issue has been fixed. Additionally security
fixes should be provided for a reasonable period in aspect of an office
environment.

The thought behind is:
Bugs are relevant not by possibility to happen but by appearence.

Therefore it might be a good idea to be as close as possible at users
*real* experience. We get the closer to it the closer our response is to
users anoyance. If we succeed doing this, we will get that users which
are greedy hunting bugs. ;o))

Because the *possibility* of a bug's existence doesn't matter much, I
think we shouldn't bother interested coworkers with boring and difficult
to learn tools blocking their machine by runnig automated tests which
never hit people's creativity to do strange things ;o)).

And last one:
The remaining dev time *after* fixing bugs is reserved for implementing
new features ;o))

In short -- draft -- not mature

Gruß/regards
-- 
Friedrich

Ansprechpartner / contact person for the "PrOOo-Box"
german language OpenOffice.org and more on CD/DVD 
http://prooo-box.org 

-- 
To unsubscribe, send an empty e-mail to discuss+unsubscribe@documentfoundation.org
All messages you send to this list will be publicly archived and cannot be deleted.
List archives are available at http://www.documentfoundation.org/lists/discuss/

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.