[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Fri, 2009-02-20 at 18:18 +0000, Mark McLoughlin wrote:
> 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.

This all sounds very sensible. To be honest, my Grand Strategy is not to
take on anything related to this project (making Rawhide more widely
used) that requires me to poke the development team for a few weeks /
months - i.e. until the people on the development list know I have some
kind of clue what the hell I'm talking about (er, I hope I do :>). I
don't think it would go down very well for me to just show up one day in
the development group with my Grand Plans For Changing Everything. You
have to wheedle your way in slowly. ;)

So I've been thinking of various things along those same lines -
although I definitely like the way you've laid that out - but not
planning to take them to the 'public formal proposal' stage for a while.
If you feel you're in a position to make this happen, though - or anyone
else is, and wants to - please do go for it and I will support you with
all my meagre strength :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]