[rfc] bug targeting in Launchpad

[Martin Pool]

2009/6/15 Jonathan Lange <jml at mumak.net>:

>> Probably the other place where it makes sense to target is when it's a
>> bug that's perhaps not critical, but it is almost done or in review or
>> trivial, and we want to make sure that the small amount of remaining
>> work does actually get done for this release.
>
> This does make sense, but it's something of a slippery slope. If the
> milestone is purely used for release blockers, it makes the RM's job
> easier, without necessarily preventing people from getting their
> patches in.

Yes, it is slippery, and it's confusing "would like" with "must".
(Robert gave similar feedback.)

Perhaps it's better to have the release milestone be only things that
must be done.  Then separately make sure that almost-done work gets
finished by driving to zero the review queue and the fix-committed and
in-progress bug lists.

> Also, I think it's important that there be one canonical list of all
> release blockers. It sucks to have to look at bundlebuggy, code
> reviews, the mailing list *and* the bug tracker to find them. A policy
> like "if it's targeted to the milestone, it's a release blocker; if
> it's not, then it's not" would be marvelous helpful.

I think it should be the milestone page, which implies there must be a
bug for it. If it's important enough to want to hit a particular
release it's not an excessive burden to create a bug record.

I think it's still useful to flag the mail with "[1.16]" but let's
also require a bug.

I'll try to turn this thread into a developer doc patch soon.
-- 
Martin <http://launchpad.net/~mbp/>