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

Mark Côté mcote at
Wed Oct 22 13:16:28 UTC 2014

On 2014-10-22 8:44 AM, Frédéric Buclin wrote:
> Le 22. 10. 14 14:22, Gervase Markham a écrit :
>> Well, making new features blockers for time-based releases doesn't make
>> sense either :-)
> Haha, good point. I fully agree with you. :)

As I clarified on the Release Process page, I agree that we should not
block releases on new features.  I foolishly let myself be talked into
delaying 5.0 for the "almost done" markdown, and I regret that now. :)

>> But my point is not so much about blocking; it is: Target Milestone
>> should indicate all bugs which are targetted at a particular release. A
>> bug is considered "targetted" at a release for one of two reasons:
>> either, the Bugzilla team will not release unless that bug is fixed, or
>> alternatively a particular developer has expressed intent that they
>> personally are going to fix the bug in time.
> I agree here too. This would also help everyone understand if such or
> such bug will be backported or not. For instance, if a bug is targetted
> 4.4, you know it will be backported. If it's targetted 5.0, you know it
> won't. This would also save the assignee some time: no need to work on a
> backport if the bug fix is not going to be accepted on stable branches.

That's fine.  I have no problems using severity=blocker for bugs which
actually block release.  I'll update the 5.0 blockers right now.


dev-apps-bugzilla mailing list
dev-apps-bugzilla at

More information about the developers mailing list