[CentOS-devel] QA accessibility

On Wed, 2009-10-14 at 17:06 -0500, Jerry Amundson wrote:
> On Mon, Sep 14, 2009 at 8:50 AM, Phil Schaffner
> <Philip.R.Schaffner at nasa.gov> wrote:
> > A message on centos-users has raised a question in my mind about the
> > openness of the QA process.  I'm pretty sure that there is no desire to
> > greatly expand the QA team, but on the other hand a few more serious QA
> > testers might be worthwhile.  I started to reply to the message below
> > with a link to an announcement of opportunity to join the QA team from
> > the centos-devel list, and possibly to add a bit to the "Contribute"
> > page, but decided it might be better to bounce the idea around here instead.
> 
> I see a need to bounce this around some more. The bottom line, whether
> or not the CentOS core group wants to admit it, is this : more people
> + more testing = more love.
> There are, of course, details as to the "people", and the "testing"
> (and for that matter,  the "love" :-), but that concerns the Who and
> the What.
> So, here, we can start the `How' of QA Accessibility. How do I, for
> example, become involved in QA to help CentOS become even better?
> 
> The "C" in CentOS is meant as "the community", not as "the clique",
> and that should apply towards every facet of the distribution.
> That said, however, I also recognize the core group's desire to limit
> noise, etc. I think the point here is that through *discussion and
> documentation* we can reach a middle ground which adds benefit to
> CentOS as a whole, but without further burden to the development core.

Still bouncing...

There are a range of opinions floating around about the openness of
developing and testing new releases.  Let's limit the current discussion
to the topic at hand: QA accessibility.  Seems to go something like this
- not all the cases below are necessarily mutually exclusive.

-----------------------------------------------------------------------

1. Public Beta open to all, with appropriate warnings about the dangers
of use on production machines.

Pros: Lots of people testing and finding/reporting bugs and issues.
Could complement case #2 or #3.

Cons: High noise level on centos-users and/or centos-devel.  Possibility
of increased support burden on core team members.  Possible negative
"publicity" and bad vibes from users with broken installs.

-----------------------------------------------------------------------

2. More open process based on the current QA model.  Document and
publicize the process for joining the QA team on the Wiki, and/or
www.centos.org.  Point seemingly qualified people to the process on MLs
and fora. Allow more vetted members to join QA.  I'd suggest going as
far as making the QA list world-readable.

Pros: More people testing and finding/reporting bugs and issues. Better
coverage of hardware platforms and wider/deeper software testing.

Cons: More traffic on QA list.  Not necessarily a bad thing, but this is
what I am advocating, so I may be prejudiced.

-----------------------------------------------------------------------

3. Current QA process - don't mess with it.

Pros: Working pretty well.

Cons: Coverage of the range of hardware platforms and software testing
has a lot of room for improvement.  People disgruntled about lack of
openness about the process.

-----------------------------------------------------------------------

What have I missed, and who falls where on the spectrum?

Phil