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'$ $. ,$.
Attachment:
signature.asc
Description: Digital signature