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

Re: bug tracking for non-RC architectures

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,
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

Reply to: