On 15/04/2012 Rob Weir wrote:
On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti wrote:
Historically, OpenOffice.org produced a numbered Release Candidate
(OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
community exactly for the purpose of looking for unknown bugs. QA activities
were planned for the RC phase and, after a few days of availability, a RC
was approved as final or rejected (and the Release Manager could, and at
times did, include fixes for previously known bugs that had been
accumulating and that were significant; none of them was a blocker in
itself, but each of them would have caused problems to users, so their
combined effect was blocking the release).
That is what we've been doing with the dev snapsots builds. Surely
you've seen the QA work Lily has done with testing them?
Sure, and it was great work. But those tests were run on versions that
are now quite outdated. Example: the spell check test asks you to verify
that no spell check is available and that dictionaries have been removed
accurately, while we all know that things are quite different in current
builds.
The traditional OpenOffice.org Quality Assurance process had two
features that I'd like to keep:
1) Full QA is run on what we release. We need to ensure that OpenOffice
works now, not that previous builds worked.
2) The community at large is involved in testing, in a specific short
period just before the release. If "Release Candidate" has a different
meaning now, call it the "Pre-Release Phase", that will end with a
"Release Candidate" we can vote on rather confidently. We can't rely on
volunteers doing QA on a regular basis, but we can very easily find
volunteers willing to stress-test a "nearly final" version in a well
defined timeframe (1-2 weeks).
I would keep this as a basis for discussing how to structure QA
activities in future (after 3.4), if others agree.
Regards,
Andrea.
