Cooperative Bug Isolation for Fedora 13

The Cooperative Bug Isolation Project (CBI) is now available for Fedora
13. CBI ( is an ongoing research effort to
find and fix bugs in the real world. We distribute specially modified
versions of popular open source software packages. These special
versions monitor their own behaviour while they run, and report back how
they work (or how they fail to work) in the hands of real users like
you. Even if you’ve never written a line of code in your life, you can
help make things better for everyone simply by using our special
bug-hunting packages.

We currently offer instrumented versions of Evolution, The GIMP, GNOME
Panel, Gnumeric, Liferea, Nautilus, Pidgin, Rhythmbox, and SPIM.
Download at <>. We support
PackageManager, yum, apt, and many other RPM updater tools; see
<> for customized
configuration help for any of our supported distributions and updater
tools. Or just download and install
to automatically configure most popular RPM updaters to use the CBI

It’s that easy! Tell your friends! Tell your neighbours! The more of
you there are, the more bugs we can find.

We still offer CBI packages for earlier releases as well, going all the
way back to Fedora 1. When and if you decide to upgrade to Fedora 13,
we’ll be ready for you. Until then, your participation remains valuable
even on older distributions.

Via Dr. Ben, the CBI guy

Out of Flamewar arises a Phoenix of Hope

I don’t remember the original post that got this whole thing going but in about 24 hours something awesome happened. The Fedora Project has set a goal turning users into contributors. If you have ANY free time and (just about) ANY skill we can find a place for you. One place where people are needed badly is testing. There are just more packages than there are testers, that’s just the way it is. There are only two ways to slove this 1. stop maintaining so many packages. If you cant find people to test it then its obvious no one uses it. This is the wrong answer. or 2. find more testers, this is the right answer. Spot came up with a great idea

… I posit an alternative suggestion:

* At firstboot, the installing user is asked if they would be willing to
participate in user-driven updates testing. It is explained to them that
in Fedora, updates to packages need to be tested by users, and that if
they opt-in, they will be prompted from PackageKit about updates which
need user testing. They can choose an update which needs testing from a
list. Once an update is selected from the list, PackageKit will apply
the update from updates-testing, then open a new window which contains:

* General update testing advice
* Package specific update testing advice (this can live on the wiki)
* A graphical selector for giving +1 (works great!), 0 (cannot determine
state) or -1 (something didn’t work)
* A text box for inputting comments

The user then submits the results, which go into Bodhi. Once results are
submitted, that update no longer appears in the PackageKit “updates
which need testing” list.

If they report a 0 or -1, they are then prompted to back out the update
by PackageKit (at their choice).

* On the backend, should a user choose to opt-in, they would be prompted
to create a FAS account (or authenticate to an existing FAS account)
(e.g. RHN handling in the past). They would _NOT_ be required to sign
the Fedora CLA in order to participate in user-driven testing, as
reported results from QA testing has already been determined to be
non-copyrightable and thus, not considered a contribution.

Each user who opts-in to perform user-driven testing will have it
flagged in their account. Each successful update testing submission will
be minimally logged (package, target, timedate stamp) and a count
incremented for unique update feedback performed.

In thanks for their testing, users will be informed (at firstboot) that
they will receive Fedora swag, both in random drawings and at certain
threshold points (give good feedback on N updates and get a Fedora
Tester T-shirt).

Users can choose to opt out at any time. …

But that wasn’t the only proposed solution. There are some that think that poping crap up at people on first boot is bad form and that we should strive to give people a running functional desktop before we start bothering them. Meh good point. So here was another solution This
one by Mike McGrath.

Random thought: We could put a pretty ajaxy signup thing on that keeps them logged in via community.

I’m thinking of something similar to how works now. With no
login you get the generic pageg. With a login you might get a more
feature rich “targeting contributors” page. If they’ve gone far enough to
do the ajax sign up, we can try to consider them a potential contributor.

This topic is still hot on the Advisory Board Mailinglist , but what are your thoughts? Would you test packages for swag? Would you test packages if there was no swag? Would you be annoyed if this was presented to you at firstboot? Let me know in the comments or link me if you put your thoughts up somewhere eles.