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 [email protected]. > * 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 [email protected] 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/
