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 _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
