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.
Announcement on CentOS-devel: http://lists.centos.org/pipermail/centos-devel/2007-February/001200.html
[CentOS-devel] CentOS 5 Beta Initial Test Release Lance Davis lance at uklinux.net Wed Feb 21 13:14:16 UTC 2007
We are about to release an initial internal test release of CentOS 5 beta to our qa team.
If folks here want to be a part of that test they need to join the centos-qa list (http://lists.centos.org/mailman/listinfo/centos-qa) and send a message to this list (centos-devel) saying that they would like to be a part of the qa process and join the qa team, with details of relevant experience if you are not known to the core developers.
Membership of the centos-qa list will then be approved.
Lance
-- uklinux.net - The ISP of choice for the discerning Linux user.
http://wiki.centos.org/Contribute#head-1c14314cdaa251daca6c3a79ff7510c5c05d4...
Proposed addition to Contribute: "Testing of new releases is done by the CentOS Quality Assurance (QA) team. People interested in helping with QA should first join the [http://lists.centos.org/mailman/listinfo/centos-devel CentOS Developer's list] and [http://lists.centos.org/mailman/listinfo/centos-qa CentOS QA list] and send a message to mailto:CentOS-devel@centos.org, with details of relevant experience if not already known to the core developers, saying that they would like to join the QA team."
I notice that the QA list is not on the CentOS list of lists. Not sure if this is by design, or has just been overlooked.
http://lists.centos.org/mailman/listinfo
Phil
-------- Original Message -------- Subject: [CentOS] Centos 5.4 'prerelease-access' - is there such a thing? Date: Sat, 12 Sep 2009 08:22:17 -0500 From: Peter l Jakobi lists@kefk.oa.shuttle.de Reply-To: CentOS mailing list centos@centos.org To: centos@centos.org centos@centos.org
Hi,
excluding the Frankengrade from CENTOS5.3 to upstream RHEL5.4, is there are procedure / repository access / nightly builds / ... to what will be CENTOS 5.4?
URLs? Howtos? Discussion threads or notes?
I checked help, wiki and forums and google, but came up empty.
Of course, this kind of use is depending on the way the new upstream RHEL sources are processed, so maybe there won't be a complete set of packages at all until maybe one or two weeks before the release. But again I got no lucky search hits for this kind of internals either.
I'll gladly collect and summarize for a (hopefully easier locatable) wiki-page to be :).
cu, Peter
Dear Phil,
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.
This is what I wrote a few weeks ago and I would really appreciate an open and transparent QA process. I personally don't see any good reason why QA access should not be granted to ppl willing to help out.
Best Regards Marcus
On Mon, 14 Sep 2009, Marcus Moeller wrote:
open and transparent QA process. I personally don't see any good reason why QA access should not be granted to ppl willing to help out.
My thoughts. I anticipate that an open QA process would: - generate bug reports to the main mailing list, (wrong place) causing reply firestorm of 'is FOO really broken' and all the echoes that make that list
- not produce a true tests, but rather just more 'works here' and more 'me too' echo noise
- cause us to have to re-version (bump even more) upstream 'release' values on any package we release to QA, as we will end up with 'testers' of doubious skills demanding hand holding which we will have to give to avoid reputational damage, AND those QA packages WILL leak into the general distribution -- See the problems with the expedited security release so far
There are LOTS of reasons not to take on gratutious load -- these are my top of mind obvious ones. If people want to bleed, the NEED TO GO TO FEDORA so the changes flow back down in our future.
We are an enterprise rebuild as the core product. Nothing more
-- Russ herrold
Dear Russ,
open and transparent QA process. I personally don't see any good reason why QA access should not be granted to ppl willing to help out.
My thoughts. I anticipate that an open QA process would: - generate bug reports to the main mailing list, (wrong place) causing reply firestorm of 'is FOO really broken' and all the echoes that make that list
I guess it's not about opening QA completely but to outline how one who is really interested can take part in this process and not to limit the number of participants with 'slots'.
Best Regards Marcus
R P Herrold wrote:
open and transparent QA process. I personally don't see any good reason why QA access should not be granted to ppl willing to help out.
My thoughts. I anticipate that an open QA process would:
- generate bug reports to the main mailing list,
(wrong place) causing reply firestorm of 'is FOO really broken' and all the echoes that make that list
I'd trade a lot of spurious noise on the mail list for extra chances to find out that FOO really is broken when dropped in certain real-world circumstances that may not be tested otherwise before being released to places that don't want surprises.
There are LOTS of reasons not to take on gratutious load -- these are my top of mind obvious ones. If people want to bleed, the NEED TO GO TO FEDORA so the changes flow back down in our future.
We are an enterprise rebuild as the core product. Nothing more
But you aren't _exactly_ the core product. There might be a hint of the difference in the latest kernel release but since only one person has mentioned the problem it isn't quite clear what it is.
On Mon, Sep 14, 2009 at 8:50 AM, Phil Schaffner Philip.R.Schaffner@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.
Thanks, jerry
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@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
On Fri, 2009-10-16 at 21:22 -0400, Jeff Johnson wrote:
On Oct 16, 2009, at 9:03 PM, Phil Schaffner wrote:
What have I missed, and who falls where on the spectrum?
I tend to hang out somewhere between mauve and indigo around 4453 Angstroms.
hth
73 de Jeff
I'm more into X-band - around 10 GHz or 3 cm wavelength. Very different part of the spectrum - but works well for weather radar.
Phil
-
Jeff Johnson -
Jerry Amundson -
Les Mikesell -
Marcus Moeller -
Phil Schaffner -
Phil Schaffner -
R P Herrold