Priority Field descriptions

0 views
Skip to first unread message

Mike Schroepfer

unread,
Dec 18, 2007, 11:49:36 AM12/18/07
to
Hey Folks,

At the last Gecko/FF3 meeting we tried to agree on a super-short and
crisp definition of priorities to make sure all area owners and using
the same criteria. Here's what I remember:

P1: Blocks next milestone
P2: Blocks final release
P3: Individual bugs don't block final, but we don't want to ship with
too many of these
P4: Will take the change but doesn't block the release
P5: Will take it if low risk - but very much nice to have

(we didn't talk as much about P4/P5 so those are much more fuzzy)

We also said that we are not expecting folks to do a big re-prio as
we've already done that - just trying to make sure everyone's using the
same criteria as we touch bugs.

Does this jive with everyone?

Best,


Gavin Sharp

unread,
Dec 18, 2007, 12:05:43 PM12/18/07
to Mike Schroepfer, dev-pl...@lists.mozilla.org
On Dec 18, 2007 11:49 AM, Mike Schroepfer <sch...@mozilla.com> wrote:
> P1: Blocks next milestone
> P2: Blocks final release
> P3: Individual bugs don't block final, but we don't want to ship with
> too many of these
> P4: Will take the change but doesn't block the release
> P5: Will take it if low risk - but very much nice to have

I'm a bit confused - is this proposal talking only about the set of
bugs marked "blocking-firefox+" or "blocking1.9+"? The definition of
blocking+ used to be P1-P2 (and effectively P3) on that list, and we
had wanted+ for P4/P5. If we're going to start having bugs marked
"blocking1.9+" that we "will take but doesn't block the release"
perhaps we should change the flag name to something like
"tracking-1.9"...

Gavin

Gervase Markham

unread,
Dec 18, 2007, 12:52:06 PM12/18/07
to
Gavin Sharp wrote:
> On Dec 18, 2007 11:49 AM, Mike Schroepfer <sch...@mozilla.com> wrote:
>> P1: Blocks next milestone
>> P2: Blocks final release
>> P3: Individual bugs don't block final, but we don't want to ship with
>> too many of these
>> P4: Will take the change but doesn't block the release
>> P5: Will take it if low risk - but very much nice to have
>
> I'm a bit confused - is this proposal talking only about the set of
> bugs marked "blocking-firefox+" or "blocking1.9+"?

It seems to me that there is definitely an overlap in meaning here,
which is unfortunate. We seem to have slid into using flags as
pseudo-priority. blocking-foo is like P1, wanted-foo is a bit like P3,
and so on.

Gerv

Mike Schroepfer

unread,
Dec 18, 2007, 4:26:27 PM12/18/07
to Gavin Sharp, dev-pl...@lists.mozilla.org

This is for both FF and 1.9. In practice people have been using P4/P5 +
blocking+ hence the confusion. So I think you are right - we should
move P4/P5's blocking+ to wanted+ and then blocking+ P1-P3 becomes much
more clear. I'd propose we do this right after the holidays (Say Jan 2)
so that folks are not slowed down by having to ask for approvals and
gives folks plenty of time to adjust priorities if they want to make
sure something really gets done. We can still, obviously, take any
wanted or other bugs with a approval1.9+ patch approval. At least on
the Gecko side 70% of bugs are p1-p3 so the P4-P5 are in the minority
here - but I mostly want to make sure the bugs are clear to everyone
watching.

Best,

Schrep

Mike Schroepfer

unread,
Dec 18, 2007, 4:26:27 PM12/18/07
to Gavin Sharp, dev-pl...@lists.mozilla.org

This is for both FF and 1.9. In practice people have been using P4/P5 +

Boris Zbarsky

unread,
Dec 18, 2007, 8:06:48 PM12/18/07
to
Mike Schroepfer wrote:
> P3: Individual bugs don't block final, but we don't want to ship with
> too many of these
> P4: Will take the change but doesn't block the release
> P5: Will take it if low risk - but very much nice to have

Given these, there seem to be a number of bugs that should be bumped to
P3 or P2 as far as I can tell. Things like:

https://bugzilla.mozilla.org/show_bug.cgi?id=408922 should be P2

https://bugzilla.mozilla.org/show_bug.cgi?id=405894
https://bugzilla.mozilla.org/show_bug.cgi?id=405384
https://bugzilla.mozilla.org/show_bug.cgi?id=403181
https://bugzilla.mozilla.org/show_bug.cgi?id=400717
https://bugzilla.mozilla.org/show_bug.cgi?id=398983
https://bugzilla.mozilla.org/show_bug.cgi?id=396002
https://bugzilla.mozilla.org/show_bug.cgi?id=396315

should be P3, possibly. Though some may want to stay P4.

https://bugzilla.mozilla.org/show_bug.cgi?id=400075 should be P3 or
higher; I'd tend to P2.

I mostly looked at gfx/widget here, but I'm sure other components have
similar things...

What's the process for setting what is perceived as an incorrect
priority? Just unset it with a comment explaining why?

-Boris

Boris Zbarsky

unread,
Dec 18, 2007, 8:21:46 PM12/18/07
to
Boris Zbarsky wrote:
> Given these, there seem to be a number of bugs that should be bumped to
> P3 or P2 as far as I can tell.

Looking at the layout P4/P5 blockers, of the 30 bugs in the list 12 are
crashes. Two of those are security-sensitive. I'm not sure any of
those should be below P3 given the priority descriptions.

Of the remaining 18:

https://bugzilla.mozilla.org/show_bug.cgi?id=400578 should perhaps be a
P3, since it either means a bad experience for users or font-size-adjust
not being usable by sites.

https://bugzilla.mozilla.org/show_bug.cgi?id=402940 is a pretty serious
regression that makes it more or less impossible to fill out some forms
correctly. I wouldn't put it below P3.

https://bugzilla.mozilla.org/show_bug.cgi?id=403369 should probably be a P2.

I haven't looked at any other components yet, but perhaps some
reprioritization with the new meanings in mind is in fact called for...

-Boris

Mike Schroepfer

unread,
Dec 18, 2007, 11:41:54 PM12/18/07
to Boris Zbarsky

Hey there,

Process is simple if it's in your area just go ahead and make the change
with a comment as to why. If it is owned by someone else just comment
as to what you think the change should be.

Mike Schroepfer

unread,
Dec 18, 2007, 11:43:00 PM12/18/07
to Boris Zbarsky

Hrm. I had hoped not. Let's take a look at the list you generated
here during the next triage.

Reply all
Reply to author
Forward
0 new messages