On Tue, Dec 27, 2005 at 03:26:10PM -0800, Steve Langasek wrote: > Hi folks, > > For architectures that are not release candidates, we are going to need > another way to track "release critical" bugs. The whole point of having > architecture criteria is so the project can give higher priority to issues > affecting release architectures (or all architectures) than to issues that > are specific to an architecture that isn't meeting our standards for > releasability; and we're not doing that very effectively if we leave such > architecture-specific bugs at RC severity. OTOH, we don't want to lose > sight of them by just downgrading the severities, as this would make it > awkward to reintroduce the architecture as a release candidate without also > silently reintroducing RC bugs. Hi release manager on high, my impression is to create a simple data file to hold release canidate archs (or a script that would dynamicly create this based on rc goals [I think I saw this on Ingo's site]). Then mod the tools/scripts that display/count RC bugs thus not touching bug reporting tools or the BTS, thus if the canidate list changes, the bugs will simply be added to the views/counts without needing to touch the BTS. happy $holiday and $year++ to your and yours and the four-legged one, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$$$$$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ "' `$ $$' `$ $$ $ $$ggggg$ $ $ $ ,$P"" $ $ $ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $ $ `Y$$P'$. `Y$$$$P $$$P"' ,$. `Y$$P'$ $. ,$.
Description: Digital signature