[rfc] bug targeting in Launchpad

[Jonathan Lange]

On Thu, Jun 11, 2009 at 10:01 AM, Martin Pool<mbp at sourcefrog.net> wrote:
...
> Therefore I think we should target bugs to releases only when it's
> something really critical to that release: we'd drop most other things
> to get this fixed, and we'd at least seriously consider slipping the
> release to put it in.  I think it's ok to have a bit of safety margin,
> by marking things that _might_ be needed or we might change our mind,
> but if we find we're regularly having bugs not hit the release they're
> targeted to our targeting is not honest.
>
> "I'd like to do this for 1.x" is not a good use of this marker.  If
> you want to do it soon, assign it to yourself, and when you start mark
> it in progress.
>

I think this makes a lot of sense.

Rob's pointed out in other threads that the RM perhaps does too much
wrangling. For my part, most of the wrangling I did was looking at the
list of bugs on the 1.16 milestone and asking "is it done?", "does it
need to be there?". There would have been less wrangling were the list
shorter & more clearly focused.

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

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.

jml