RawhideBlocker [was Re: QA group activities + goals discussion]

[Mark McLoughlin]

On Mon, 2009-02-16 at 14:38 -0800, Adam Williamson wrote:

> 1. Increase participation in Rawhide: it provides a huge benefit in
> terms of identifying issues and having them fixed quickly and early in
> the cycle.

Agreed - rawhide has a bad rep, and lots of people tend to avoid it. It
has been improving lately, but we should keep trying out new things to
get it to the stage that anyone involved in Fedora development should be
able to run rawhide.

Here's a snippet from an old email on time based release processes that
still really resonates with me when thinking about rawhide:

  http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html

  The goal of the unstable branch is to be an exciting and 
  forward-moving but USABLE BY TESTERS piece of software. This is just 
  the "release early, release often" principle.
  ...
  The unstable branch must always be dogfood-quality. If testers can't
  test it by using it daily, they can't make the jump. If the unstable
  branch becomes too unstable, we can't release it on a reliable
  schedule, so we have to start breaking the stable branch as a stopgap.

Here's a suggestion:

  1) Come up with a rough definition of what it means for rawhide to be 
     considered "dogfoodable" - e.g. installs, boots, networking works, 
     desktop and core apps usable, etc. etc.

  2) Create a RawhideBlocker tracker bug - add anything to it that 
     breaks something on the dogfoodable list

  3) Post details to fedora-devel-list of any new bug added to
     RawhideBlocker, cc-ing the package owners

  4) Harass package owners, and encourage others to help, until the 
     issue is resolved

  5) Keep the list small, so that "OMG, it's blocking rawhide" is a
     real incentive for people to sort problems out. If the list grows 
     too long, consider lowering the dogfoodable bar.

Cheers,
Mark.