<br><br><div class="gmail_quote">On Fri, Dec 3, 2010 at 5:36 PM, Adam Williamson <span dir="ltr"><<a href="mailto:awilliam@redhat.com">awilliam@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Fri, 2010-12-03 at 17:19 -0500, Greg DeKoenigsberg wrote:<br>
<br>
><br>
> Joining a "Generic QA Group" to help with the QA of FooDE seems like<br>
> unnecessary overhead, unless it's *very clear* what advantage joining<br>
> that group confers. It may well be easier to simply have the FooDE<br>
> SIG hold their own meetings, build their own schedules, do their own<br>
> QA, write their own release notes, and do their own marketing. What<br>
> clear value proposition is there to matrix this work across different<br>
> SIGs/subprojects to the FooDE folks? Because it's not clear to me,<br>
> and it doesn't seem like it's clear to the folks who are working on<br>
> the various Spins, either.<br>
<br>
</div>Um. To me it seems the exact opposite: the overhead comes with each SIG<br>
having to establish its own QA, marketing, documentation and releng<br>
processes.<br>
<br>
To take a practical example - last cycle, we (QA group) implemented a<br>
desktop release validation testing process.<br>
<br>
<a href="https://fedoraproject.org/wiki/QA:Desktop_validation_testing" target="_blank">https://fedoraproject.org/wiki/QA:Desktop_validation_testing</a><br>
<br>
for each release point, we provide a test matrix:<br>
<br>
<a href="https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test" target="_blank">https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test</a><br>
<br>
which obviously includes test cases, which we also provided, which are<br>
carefully designed to be as generic as possible so that the process<br>
covers all desktops. The matrix currently lists the primary desktops<br>
plus Sugar, and can easily be extended to cover any other desktop. It<br>
costs me almost no more work to update this for five desktops for each<br>
release than it would to update it for one desktop.<br>
<br>
By doing this, we provide a framework for release validation testing for<br>
*all* desktops. To me, it would seem to involve far more overhead for<br>
each desktop spin SIG to come up with its own process for doing release<br>
validation testing. It seems far more sensible for the project-wide QA<br>
group to work to provide generically applicable frameworks like this.<br>
Now all the spin SIGs have to do to get their release validation testing<br>
done is to go to the matrix page, run the test cases, and plug in the<br>
results. That's efficient use of resources, and co-ordination of<br>
generic, project-wide resources with spin-specific resources.<br>
<br>
This doesn't even really require any spin people to 'join' QA group<br>
(though all that's involved in joining the QA group is signing up for<br>
the test mailing list anyway). It costs about five seconds to add each<br>
desktop list to the CC list for each pre-release point. Or we can<br>
require the SIGs to sign someone up to test-announce and just send the<br>
announce there. But that seems like a very minor point to get hung up<br>
on.<br></blockquote><div><br>Sorry Adam. You're exactly right. I should have made it clear again: as I posted earlier in the thread, it seems like QA has gone the farthest down the line towards getting this right, and again I wonder how other "service" groups might learn from QA's example.<br>
<br>--g<br></div></div>