ubuntu-defect-analysts team mailing list archive

[Kate Stewart <kate.stewart@xxxxxxxxxxxxx>]

Hi, 
   I was working through the bugs pulling together the agenda for this
week, and noticed a significant number of the A2 ISO testing bugs
haven't been looked at yet.  For instance, state New has 9 (out of 69).
Also there are some with importance that hasn't been set
( importance=undefined 12/39).
http://iso.qa.ubuntu.com/qatracker/report

   To get the bugs to the attention of developers, they generally need
to be confirmed (ideally triaged), and have the importance set.
To find the release critical ones early (generally high/critical and
milestoned by an analyst or developer to the release), maximizes our
chances of getting them fixed. 

   Given these are bugs found during testing of the A2 iso images,
mostly from the mandatory tests, I tend to give them a higher bit of
focus, since they're likely to reoccur in A3 testing if nothing is
done.   

   Where some help is needed, is that there seems to be a gap between
the bugs being reported, and a scrub to get them all with accurate
importance set and figured out if real or not.   Note, this is just
specifically for the ones found during iso testing.   

   Now not all of these bugs are in each of your teams, but some of them
are in packages your team cares about.  For those packages that your
team cares about,  does it make sense for each of the analysts to take a
pass at the bugs, and make sure the state and importance are accurate?
Other suggestions on how we can get quicker proper disposition
(importance set and milestoned/release targetted if appropriate) of the
ISO bugs?   We probably need to identify the gap packages and figure out
if a team needs to care about them or not. 

Its not clear how to help get Kubuntu, Edubuntu, etc. bugs on the list
sorted in a timely manner, and we'll need to involve those communities
to figure out solutions, but I figure if we can come up some ideas on
dealing with Ubuntu's bugs its a start. :)

Kate