On 11/03/13 09:41 AM, Kevin Fenzi wrote:
Greetings. I'd like to propose we create a rawhide tracker bug. Probibly name it: RawhideBlocker (But I don't care what colour the bikeshed is) This bug would be used for the following types of bugs against the 'rawhide' version: - bugs that prevent the daily rawhide compose from completing. (In practice this can only be a small subset of packages used for the compose in the chroot) - bugs that break the rawhide buildroot. In practice these are usually noticed pretty quickly and the offending build is just untagged until it can be fixed, but there could be cases where the fix is more complex and has a bug associated with it. - bugs that cause a large number of rawhide systems to be unbootable. This would be things like dracut or kernel or glibc or systemd issues that cause most rawhide installs to fail to boot. (we could add additional criteria as we go) The idea is that folks running rawhide could watch this bug and more easily see issues that are major as they appear and know when they got fixed. They could also add bugs to this and developers could see that the bug is high priority and more resources could be brought to bear on it. Additionally we could gain some insight into how often these kind of bugs happen and how long it takes to fix them. This would of course require people watching the bug to note any bugs added to it that are NOT in the above criteria, but I think that should be easily possible with enough people watching the bug.
I endorse this product and/or service, so long as it's kept light and simple.
I love the big heavy stable release blocker process, but Rawhide's a different kettle of fish, and this bug wouldn't be used as a part of release validation: it's just there to give Rawhide maintainers a handy central reference point where they can see the most important bugs affecting Rawhide.
So I'm in favour of keeping it entirely informal: just create the bug, let people mark bugs as blocking it, and have a person or small group of people weed it on a case-by-case and entirely arbitrary basis, just the way I think is _terrible_ for stable releases, because it would work fine for Rawhide. We can write up some guidelines for what should be put on the tracker if we really want, but I don't think even that is strictly 100% necessary.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
