Request: please consider clarifying the project's position on Spins

[Adam Williamson]

On Fri, 2010-12-03 at 17:19 -0500, Greg DeKoenigsberg wrote:

> 
> Joining a "Generic QA Group" to help with the QA of FooDE seems like
> unnecessary overhead, unless it's *very clear* what advantage joining
> that group confers.  It may well be easier to simply have the FooDE
> SIG hold their own meetings, build their own schedules, do their own
> QA, write their own release notes, and do their own marketing.  What
> clear value proposition is there to matrix this work across different
> SIGs/subprojects to the FooDE folks?  Because it's not clear to me,
> and it doesn't seem like it's clear to the folks who are working on
> the various Spins, either.

Um. To me it seems the exact opposite: the overhead comes with each SIG
having to establish its own QA, marketing, documentation and releng
processes.

To take a practical example - last cycle, we (QA group) implemented a
desktop release validation testing process.

https://fedoraproject.org/wiki/QA:Desktop_validation_testing

for each release point, we provide a test matrix:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

which obviously includes test cases, which we also provided, which are
carefully designed to be as generic as possible so that the process
covers all desktops. The matrix currently lists the primary desktops
plus Sugar, and can easily be extended to cover any other desktop. It
costs me almost no more work to update this for five desktops for each
release than it would to update it for one desktop.

By doing this, we provide a framework for release validation testing for
*all* desktops. To me, it would seem to involve far more overhead for
each desktop spin SIG to come up with its own process for doing release
validation testing. It seems far more sensible for the project-wide QA
group to work to provide generically applicable frameworks like this.
Now all the spin SIGs have to do to get their release validation testing
done is to go to the matrix page, run the test cases, and plug in the
results. That's efficient use of resources, and co-ordination of
generic, project-wide resources with spin-specific resources.

This doesn't even really require any spin people to 'join' QA group
(though all that's involved in joining the QA group is signing up for
the test mailing list anyway). It costs about five seconds to add each
desktop list to the CC list for each pre-release point. Or we can
require the SIGs to sign someone up to test-announce and just send the
announce there. But that seems like a very minor point to get hung up
on.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net