Target Milestones, cont'd, and release-process documentation

Gervase Markham gerv at
Wed Oct 22 10:43:21 UTC 2014

On 22/10/14 03:36, Mark Côté wrote:
> Thinking more about the Target Milestone, in order to logically complete
> the thought from September, at our meeting in 11.5 hours I will propose
> that we further restrict usage of Target Milestone on Bugzilla bugs to
> indicate true blockers, that is, bugs that *must* be fixed before
> release. 

This seems odd to me. Surely severity=blocker is the way of finding

I suggest that Target Milestone should be set if the bug has an actual
assignee and the assignee's personal plan means that the work will be
finished before the release in question. The release manager would have
the authority, when the release approaches, to push out bugs that he
thinks are too high risk to land at that point.

This means that if anyone looks at a list of bugs with TM=5.0, they will
see a list of bugs where either someone is actively trying to fix the
bug before 5.0, or the Bugzilla team have decided it's a requirement
that the bug is fixed before 5.0. That seems like a useful list.

> The idea is that there should be a very simple, accurate way
> to see what we're waiting on in order to release a new version (or
> release candidate).  

I agree with this sentiment, but I think the search should be:


rather than



More information about the developers mailing list