Re: [tdf-discuss] QA Infrastructure

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/