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

[Mark Côté]

When finally recording the decision regarding Target Milestones from
September, I discovered that our release process does not appear to have
any documentation, on the wiki at least, so I added a new page[1].

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. 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). Thus, we should amend the decision from last month
to exclude "Bugs that are being actively worked on and are anticipated
to be finished before the next release", keeping only "bugs officially
designated as blockers" and adding "by the Project Lead or Assistant
Project Leads" for further clarity.

Mark

[1] https://wiki.mozilla.org/Bugzilla:Release_Process
--
Mark Côté
Assistant Project Lead, Bugzilla
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-***@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-b

[Gervase Markham]

Post by Mark Côté
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
blockers?

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.

Post by Mark Côté
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:

target_milestone=Bugzilla5.0&severity=blocker

rather than

target_milestone=Bugzilla5.0

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>

[Frédéric Buclin]

Post by Gervase Markham
This seems odd to me. Surely severity=blocker is the way of finding
blockers?

Errr.... so you will no longer use the blocking4.x flags?

IMO, setting severity=blocker for new features doesn't make sense. To
me, severity=blocker means that Bugzilla is severely broken due to that
bug. It shouldn't represent bugs which you simply want for the next
releases. The only exceptions are release tracking bugs.

LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>

[Gervase Markham]

Post by Frédéric Buclin

Post by Gervase Markham
This seems odd to me. Surely severity=blocker is the way of finding
blockers?

Errr.... so you will no longer use the blocking4.x flags?
IMO, setting severity=blocker for new features doesn't make sense.

Well, making new features blockers for time-based releases doesn't make
sense either :-)

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.

If someone goes to a bug and wonders "when will this be fixed by?", they
should be able to look at the TM field and either see a release number,
or "---"/"Future"/whatever, and understand the best estimate for its
being fixed.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>

[Frédéric Buclin]

Post by Gervase Markham
Well, making new features blockers for time-based releases doesn't make
sense either :-)

Haha, good point. I fully agree with you. :)

Post by Gervase Markham
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
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.

LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>

[Mark Côté]

Post by Frédéric Buclin

Post by Gervase Markham
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. :)

Post by Frédéric Buclin

Post by Gervase Markham
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
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.

Mark


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-***@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzill

[Mark Côté]

Post by Frédéric Buclin

Post by Gervase Markham
This seems odd to me. Surely severity=blocker is the way of finding
blockers?

Errr.... so you will no longer use the blocking4.x flags?

I fully admit to not even knowing about those flags; we don't seem to
use them very often. I'm not sure how useful they are nowadays since we
only want to block releases for actual blocker bugs. As I stated in my
other post, using severity=blocker seems adequate.

Mark


_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-***@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-

[Frédéric Buclin]

Post by Mark Côté
I fully admit to not even knowing about those flags; we don't seem to
use them very often. I'm not sure how useful they are nowadays since we
only want to block releases for actual blocker bugs. As I stated in my
other post, using severity=blocker seems adequate.

We used those flags for years (we were already using them in 2004 when I
joined the project). It would make more sense for you to learn about
them than breaking well established tracking rules (and making some
existing saved searches useless).

We use them when there is a point to use them. We don't mark everything
as blockers just for fun. If you want a very recent example of using
such flags, look at https://bugzilla.mozilla.org/show_bug.cgi?id=1075578

LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>

[David Lawrence]

The blocker flags are used mainly for minor point releases such as blocker4.4.6?
The target milestone will be set to the lowest major release series we will be
releasing for. So if we have a security fix for 4.0, 4.2, 4.4, and devel the
target milestone would be set to 4.0 and the blocker flags would be
blocker4.0.x?, blocker4.2.x? and blocker4.4.x respectively.

dkl

Post by Mark Côté

Post by Frédéric Buclin

Post by Gervase Markham
This seems odd to me. Surely severity=blocker is the way of finding
blockers?

Errr.... so you will no longer use the blocking4.x flags?

I fully admit to not even knowing about those flags; we don't seem to
use them very often. I'm not sure how useful they are nowadays since we
only want to block releases for actual blocker bugs. As I stated in my
other post, using severity=blocker seems adequate.
Mark
_______________________________________________
dev-apps-bugzilla mailing list
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-

[Frédéric Buclin]

Post by David Lawrence
The blocker flags are used mainly for minor point releases

We also used them for major releases once we branched. For instance, we
created the blocking4.4 flag once the 4.4 branch was created.


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=gcbd-developers-Uylq5CNFT+***@public.gmane.org>