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

[Greg DeKoenigsberg]

On Fri, Dec 3, 2010 at 5:36 PM, Adam Williamson <awilliam at redhat.com> wrote:

> 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.
>

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.

--g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20101203/846e152b/attachment.html