Release Targeting and Milestones

Brian Murray brian at ubuntu.com
Tue Feb 8 16:53:58 UTC 2011


On Mon, Feb 07, 2011 at 05:13:29PM -0600, Kate Stewart wrote:
> Brian,  Thank you for bringing this up. 
> 
> On Mon, 2011-02-07 at 14:36 -0800, Brian Murray wrote:
> > I've recently been reviewing bug reports that are targeted for a release
> > of Ubuntu or have a milestone set.  From what I've observed there is a
> > disparity between https://wiki.ubuntu.com/RCBugTargetting and what
> > really happens.
> > 
> > Examples of the disparity I've found include:
> > 
> > Bug tasks having a milestone set which are release critical sometimes
> > are not targeted to the release.  The wiki page indicates that these
> > should have a release task.  I believe the error here is not with the
> > wiki page but with not targeting the bug to the release.
> > 
> > Bug tasks being targeted to the release (e.g. having a Natty task) and
> > not being assigned to anyone.  The wiki page indicates that the tasks
> > should have an assignee.  It is important for bugs to be on release
> > team's radar especially if they don't have an assignee so I think the
> > wiki page should be modified in this case.
> 
> If the actual assignee isn't known, I suggest that the team it likely
> belongs to be flagged, so it shows up on some team's radar.  (Teams are
> good at reassigning if it isn't in their problem space ;) )   Anything
> that is release critical/high needs to have an owner/go to point.

In which case I'd like to change the language from:

"the nomination should not be accepted without finding someone to do the
work on the bug."

to

"the nomination should not be accepted without assigning the bug task to
a person or team."

> There is another concern I'd like to also bring up, since it is related.
> When working through the bugs found during the Alpha 2 release last
> week, I noticed that that priorities for the bugs weren't being set.
> Again, I would encourage folks are on the bug squad, who have the
> knowledge and ability, to make an initial assignment of the importance,
> rather than leaving it blank.  This will help the developers and release
> management figure out which ones to focus on, when time is critical.

Yes, I've always been a firm believer that a bug task's importance
should be set as soon as possible.  Even if we don't have enough
information to know if the bug is real (e.g. it is Incomplete) one can
set the importance presuming it is and adjust it up or down later.

-- 
Brian Murray
Ubuntu Bug Master
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110208/ce2b3c6f/attachment.pgp>


More information about the ubuntu-devel mailing list