Spins proposals

[Stephen John Smoogen]

On Thu, Apr 3, 2008 at 9:44 AM, Will Woods <wwoods at redhat.com> wrote:
> On Wed, 2008-04-02 at 09:06 -0800, Jeff Spaleta wrote:
>
>  >         * Fedora QA is tasked with testing all the release spins.
>  >         Nominally being part of that team, I don't think QA has the
>  >         resources (ie) enough people involved considering that we have
>  >         a six month release cycle and lots of bugs to deal with
>  >
>  > How QA gets the testing done is QA's perview. But the tasking is most
>  > certaintly correctly scoped.
>  >
>  > I will be blunt.  I think we've had a significant problem with the QA
>  > process for multiple releases now.   We must find a way to organize
>  > volunteer labor better with regard to QA..generally.
>
>  And here we have a beautifully ironic illustration of the real problem
>  with QA:
>
>  It took me a day to respond to this email because I was too busy:
>  - running the QA meeting,
>  - triaging the F9Blocker/F9Tracker lists,
>  - retesting bugs that should be fixed,
>  - testing upgrades from F8,
>  - testing fixed builds for problems in rawhide, and
>  - filing bug reports for new problems found.
>
>  Get it? I'm too busy *doing* QA to *improve* QA. I'm too understaffed to
>  work on staffing up. Chicken, meet egg.
>
>  Now. If you'd care to expand on *your* thoughts on the problems with the
>  QA Process, I'm all ears.
>
>

Long but important rant shortened... my views are the following:

1) QA is understaffed. While QA is always understaffed, it is
currently at Wanger levels of understaffed... the paid for QA people
are not able to think straight because they are always behind, always
getting more work, and deadlines are always there.  Throwing more
people at this point won't help unless you are going to say its ok for
the current QA people to stop what they are doing and work on
improving things.

2) Release times for QA are always stressful because every not found
bug is their fault, and every found bug that delays things are their
fault. And at a certain point the stress is so high that even helping
hands look like more whips. [Just like a starving dog will bite a
rescuer's hand...]

3) QA only seems to get a focus at the worst times... when things are
hitting the fan. You want to improve QA, do it when there isn't a
release. The only times I have seen QA improve at companies is when
someone high enough says "This shit is not going to go on any more."
and people are beaten out of the habit of viewing QA as something that
comes at the end of a project. And its a beating that has to happen
quite a bit because well.. we always have something on our mind that
is more important (like getting a build system, a package, etc done)

4) If you are not seeing your QA people at meetings, at gatherings,
doing their weekly blog etc.. you need to stop whatever you think is
currently more important than QA and figure out where things are
broken. Otherwise you might as well just get rid of QA because they
are only being viewed as an expense at that point.

Grumpy old man smooge will now shut-up.


-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"