blockers should...

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

blockers should...

Rob Sayre-2
...block the release

<rant>

Release drivers,

Please don't assign a bug to someone who doesn't care about it, and then
remove the blocking flag a week before the release because the "bug
hasn't seen much progress and we are less than a week from code freeze.
we will still take a patch, but are not going to hold the release for it."

</rant>

-Rob Sayre
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

L. David Baron
On Friday 2007-01-12 18:27 -0500, Robert Sayre wrote:

> ...block the release
>
> <rant>
>
> Release drivers,
>
> Please don't assign a bug to someone who doesn't care about it, and then
> remove the blocking flag a week before the release because the "bug
> hasn't seen much progress and we are less than a week from code freeze.
> we will still take a patch, but are not going to hold the release for it."
>
> </rant>
blocking+ has never really meant "blocks the release", but we
(still) don't have bugzilla UI to express what we really decide
during triage.  See
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/fb9c78418938bdc6/c68bd02e35b73ffc

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Rob Sayre-2
In reply to this post by Rob Sayre-2
L. David Baron wrote:
>
> blocking+ has never really meant "blocks the release", but we
> (still) don't have bugzilla UI to express what we really decide
> during triage.  

We've had a wanted-n.n.n flag for a while now. Is there some other flag
we need?

-Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Mike Beltzner
In reply to this post by L. David Baron
On 12-Jan-07, at 3:40 PM, L. David Baron wrote:

> blocking+ has never really meant "blocks the release", but we
> (still) don't have bugzilla UI to express what we really decide
> during triage.  See
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/ 
> thread/fb9c78418938bdc6/c68bd02e35b73ffc

Actually, by the time we'd gotten to 1.8.1rc1, blocking+ meant "will  
not ship without this resolved" and we stuck to it. As a result, we  
got increasingly picky about accepting blockers, and started doing  
other things like mentioning that we "would take patch" in the status  
whiteboard, etc.

Around the time of 1.8.1.1 the "wanted1.8.1.x" flag was introduced,  
which was a way for drivers to indicate "we think this is really  
important, and are very interested in taking it on the branch in a  
maintenance update, but not so stuck on it that we wouldn't ship."

FWIW, I totally agree with Robert's sentiment. :)

cheers,
mike


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Jay Patel-3
In reply to this post by L. David Baron
Dbaron and I have been around for a lot longer than others and
"blocking+" has meant different things to different people... so it's
difficult to define what those flags should be used for and whether
there really is a right/wrong way.

More comments inline below:

Mike Beltzner wrote:

> On 12-Jan-07, at 3:40 PM, L. David Baron wrote:
>
>> blocking+ has never really meant "blocks the release", but we
>> (still) don't have bugzilla UI to express what we really decide
>> during triage.  See
>> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/fb9c78418938bdc6/c68bd02e35b73ffc 
>>
>
> Actually, by the time we'd gotten to 1.8.1rc1, blocking+ meant "will
> not ship without this resolved" and we stuck to it. As a result, we
> got increasingly picky about accepting blockers, and started doing
> other things like mentioning that we "would take patch" in the status
> whiteboard, etc.
You guys had months and months to get that bug list down... and so
blocking+ had a different meaning during the planning and dev for
Firefox 2.0.  Your release schedule was a lot longer and there was
plenty of time to mark bugs blocking and then take them off as decided
during your meetings.  It is VERY different when working with
security/maintenance releases... so I believe the meaning of blocking+
changes for point releases.
>
> Around the time of 1.8.1.1 the "wanted1.8.1.x" flag was introduced,
> which was a way for drivers to indicate "we think this is really
> important, and are very interested in taking it on the branch in a
> maintenance update, but not so stuck on it that we wouldn't ship."
We added "wanted" flags to move bugs that were blockers for 1.8.1.1
(pushed out after 1.8.1 release) but did not get the traction we needed
to get them fixed during that release cycle... but we still "want" a fix
if one shows up (because they could potentially become true blockers if
the exploit is made public or other bad things happen).

However, the "wanted" status is only temporary for some bugs, because we
start each new point release cycle by triaging the "wanted" bugs and
upgrade some of them to "blocking+" if we feel it is something we really
should try to fix for that release.   The "wanted" flag is still fairly
new and developers still don't see a "wanted" flag as something that
could potentially block a release...and therefore probably won't pay as
much attention to them as they do "blocking+" bugs.

We are using "blocking+" to mark any bugs that we really would like to
have for a release based on our usual criteria (security vulnerability,
topcrasher, regression, etc)... but as the development cycle winds down,
some of those don't get the traction we hoped for and it is not
realistic to block a security release for some of them... since we are
always on a tight schedule... so we move them back to "wanted".

> FWIW, I totally agree with Robert's sentiment. :)
I agree that the way we use the "wanted" keyword is not ideal, since it
requires a log of flag setting/resetting... but it is working for us
right now.  If anyone has a better idea that will help us get through
these bugs quickly for each point release, which we try to get done in
6-8 weeks from start to finish, please feel free to share.

Mconnor was around when we decided to add the "wanted" keyword, but he
has not been very involved in triage meetings, so Dveditz and I have
started using the keywords in the best way we see fit to get through the
hundreds of bugs that show up in the blocker nomination queue each
release cycle.  If other have opinions, please let us know if you have
better ways to manage those lists.  Thanks!

- Jay

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Mike Beltzner
On 12-Jan-07, at 5:30 PM, Jay Patel wrote:

> Dbaron and I have been around for a lot longer than others and  
> "blocking+" has meant different things to different people... so  
> it's difficult to define what those flags should be used for and  
> whether there really is a right/wrong way.

The thread dbaron points out below goes over the salient points, but  
I think we shouldn't do things one way because it's "how it was  
always done". It's been pointed out that there's no way for someone  
to look at a list of bugs and understand the set of things they can  
depend on being fixed or otherwise resolved by looking at the blocker  
list, nor can they understand the barriers to completion. I  
understand that things changed, and am not saying that "never remove  
blockers, ever", but using the blocker list as a "to-do" list isn't  
the right answer either.

Regardless; a clear policy on what it means to be a blocker should  
exist, and more importantly, should be published somewhere so that  
people can know what it means.

> More comments inline below:
>
> Mike Beltzner wrote:
>> On 12-Jan-07, at 3:40 PM, L. David Baron wrote:
>>
>>> blocking+ has never really meant "blocks the release", but we
>>> (still) don't have bugzilla UI to express what we really decide
>>> during triage.  See
>>> http://groups.google.com/group/mozilla.dev.planning/browse_thread/ 
>>> thread/fb9c78418938bdc6/c68bd02e35b73ffc
>>
>> Actually, by the time we'd gotten to 1.8.1rc1, blocking+ meant  
>> "will not ship without this resolved" and we stuck to it. As a  
>> result, we got increasingly picky about accepting blockers, and  
>> started doing other things like mentioning that we "would take  
>> patch" in the status whiteboard, etc.
> You guys had months and months to get that bug list down... and so  
> blocking+ had a different meaning during the planning and dev for  
> Firefox 2.0.  Your release schedule was a lot longer and there was  
> plenty of time to mark bugs blocking and then take them off as  
> decided during your meetings.  It is VERY different when working  
> with security/maintenance releases... so I believe the meaning of  
> blocking+ changes for point releases.

Actually, when we decided to do it, we did it in about a week or two,  
and then maintained things by managing the blocker requests queue. I  
understand dot-dot releases are different, but I think it would just  
mean carrying a higher bar for blockers and allowing more content in  
the wanted1.8.1.x category.

Should we really come up against a wall and not be able to resolve a  
blocker before the planned ship date for a dot-dot release, when that  
bug is removed from a blocker list a full rationale for what's  
changed in the drivers' opinions to make the bug no longer fully  
block the dot-dot release should be appended, and that change should  
be made with the understanding that you're potentially hurting  
someone with a downstream dependency on that bug being fixed.

>> Around the time of 1.8.1.1 the "wanted1.8.1.x" flag was  
>> introduced, which was a way for drivers to indicate "we think this  
>> is really important, and are very interested in taking it on the  
>> branch in a maintenance update, but not so stuck on it that we  
>> wouldn't ship."
> We added "wanted" flags to move bugs that were blockers for 1.8.1.1  
> (pushed out after 1.8.1 release) but did not get the traction we  
> needed to get them fixed during that release cycle... but we still  
> "want" a fix if one shows up (because they could potentially become  
> true blockers if the exploit is made public or other bad things  
> happen).

Right, exactly. I think more things that are marked blocking1.8.1.x?  
should be moved to wanted1.8.1.x+

> However, the "wanted" status is only temporary for some bugs,  
> because we start each new point release cycle by triaging the  
> "wanted" bugs and upgrade some of them to "blocking+" if we feel it  
> is something we really should try to fix for that release.   The  
> "wanted" flag is still fairly new and developers still don't see a  
> "wanted" flag as something that could potentially block a  
> release...and therefore probably won't pay as much attention to  
> them as they do "blocking+" bugs.

See, that's bad. People aren't watching the bug status day after day,  
so moving those things around frequently (IMO!) what we want to do.

> We are using "blocking+" to mark any bugs that we really would like  
> to have for a release based on our usual criteria (security  
> vulnerability, topcrasher, regression, etc)... but as the  
> development cycle winds down, some of those don't get the traction  
> we hoped for and it is not realistic to block a security release  
> for some of them... since we are always on a tight schedule... so  
> we move them back to "wanted".

I would say that what you want to do is:

  - find the minimal set on which the release will absolutely depend
  - make those blocking
  - publish the list of highly desired ones somewhere (wiki,  
dev.planning) where devs can see 'em


>> FWIW, I totally agree with Robert's sentiment. :)
> I agree that the way we use the "wanted" keyword is not ideal,  
> since it requires a log of flag setting/resetting... but it is  
> working for us right now.  If anyone has a better idea that will  
> help us get through these bugs quickly for each point release,  
> which we try to get done in 6-8 weeks from start to finish, please  
> feel free to share.
>
> Mconnor was around when we decided to add the "wanted" keyword, but  
> he has not been very involved in triage meetings, so Dveditz and I  
> have started using the keywords in the best way we see fit to get  
> through the hundreds of bugs that show up in the blocker nomination  
> queue each release cycle.  If other have opinions, please let us  
> know if you have better ways to manage those lists.  Thanks!
>
> - Jay
>

Yup, that's all I'm doing. :)

cheers,
mike

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Rob Sayre-2
In reply to this post by Jay Patel-3
Jay Patel wrote:
>
> We are using "blocking+" to mark any bugs that we really would like to
> have for a release based on our usual criteria (security vulnerability,
> topcrasher, regression, etc)... but as the development cycle winds down,
> some of those don't get the traction we hoped for and it is not
> realistic to block a security release for some of them... since we are
> always on a tight schedule... so we move them back to "wanted".

That's my complaint. I think we should use the English definition of
"blocking". I recognize that the paragraph above describes how things
used to go, but it makes absolutely no sense: it says it's not realistic
for a blocker to block a release. Let's stop doing that.

I don't think it's a problem to have lots of bugs marked "wanted", even
if some are more wanted than others.

- Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Myk Melez
In reply to this post by Jay Patel-3
Jay Patel wrote:
> I agree that the way we use the "wanted" keyword is not ideal, since it
> requires a log of flag setting/resetting... but it is working for us
> right now.  If anyone has a better idea that will help us get through
> these bugs quickly for each point release, which we try to get done in
> 6-8 weeks from start to finish, please feel free to share.

[FWIW, although I've been around for a while, I only recently joined
drivers for the 2.0.0.2 release, so my comments may reflect that mixture
of experience and inexperience.]

I was confused about the blocking and wanted flags when I recently
joined drivers for the 2.0.0.2 release, and although I've come to
understand drivers' motivations for using them as they do, I share
others' concerns about their ambiguity.

It seems to me that there are four states a bug can be in for a branch:

1. Blocking the Next Release off the Branch (BNRB).  Using the most
literal and specific sense of "block", the release won't happen until
this bug gets fixed.

2. Critical for the Next Release off the Branch (CNRB).  This bug is
critically important, and we don't want to ship the next release without
it being fixed.  But if push comes to shove, and we don't have a fix for
it, we would be willing to ship without it.

3. Wanted for the Branch (WB).  This bug should be fixed on the branch
because it meets the branch criteria (topcrash, regression, security,
low risk/high value polish, etc.).  But it's not important enough to
warrant placement in either of the two previous categories.

4. Not Wanted for the Branch (NWB).  This bug does not meet the criteria
for being fixed on the branch.

The problem I think we're running into is that we have no way to
represent critical bugs, so we start a point release cycle by making
them blocking, and we finish it by moving the ones that didn't get fixed
into the wanted state.

And that not only takes a bunch of triage time, it also confuses
developers about how much those bugs actually matter.

I know we've wanted some Bugzilla changes to make it easier for us to
differentiate between these states, but until that happens, it seems
like we could still significantly improve the situation today by adding
one more flag per branch to represent critical bugs, f.e. critical1.8.1.x.

Then drivers could mark bugs with their actual state, we wouldn't have
to dance these bugs back and forth between states at various stages in
the release cycle, and developers would understand what drivers actually
thinks about the importance of the bugs.

Notes:

1. We could use release-specific flags for the critical state (f.e.
critical1.8.1.2), but that doesn't seem worth the effort required to
retriage them at the end of each release, since they're almost certain
to remain critical for the next release if they miss the current one.

2. A slight variation of this approach is for all
blocking/critical/wanted bugs to be marked wanted, so a blocker has
blocking+wanted flags, a critical bug has critical+wanted flags, and a
wanted bug just has the wanted flag.  Not sure what makes more sense here.

3. This approach wouldn't mean a bug couldn't change states once
triaged, of course.  It would continue to be possible for a blocker bug
to be reevaluated down the road.  We just wouldn't be marking bugs as
blockers to make them seem more important if we already know they would
lose that status in a late-in-the-cycle reevaluation.

4. I realize that the schedule for minor releases is different from that
for major releases, and we're less tolerant of schedule slip, so our
criteria for blocking is stricter for minor releases than for major
releases, yet we still want developers to take bugs targeted at minor
releases seriously.

But that doesn't seem to me to be a good reason to change the meaning of
the term "blocking" for those releases.  Years ago we used to ship
so-called "release candidates" that we knew we wouldn't ship as final
releases because they were missing fixes that were blockers for the
release.  We're the better for changing that policy so that we now only
release true RCs, and I think we'd be better off fixing the way we use
"blocker" so that we apply that term with similar rigor.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

L. David Baron
In reply to this post by Rob Sayre-2
On Friday 2007-01-12 21:19 -0500, Robert Sayre wrote:

> Jay Patel wrote:
> >
> >We are using "blocking+" to mark any bugs that we really would like to
> >have for a release based on our usual criteria (security vulnerability,
> >topcrasher, regression, etc)... but as the development cycle winds down,
> >some of those don't get the traction we hoped for and it is not
> >realistic to block a security release for some of them... since we are
> >always on a tight schedule... so we move them back to "wanted".
>
> That's my complaint. I think we should use the English definition of
> "blocking". I recognize that the paragraph above describes how things
> used to go, but it makes absolutely no sense: it says it's not realistic
> for a blocker to block a release. Let's stop doing that.
Bugs that are absolute blockers for a release are very rare.

If you have a bug that you think is a blocker, and the release were
otherwise ready, would you hold the release for a week to get that
bug fixed?  A month?  A year?  Ten years?

For how many bugs would we delay a release ten years if they were
the only serious problem with the release?  I think very few.

So if we want to have a useful state, it has to be something a
little less rigorous.  The question is only how much less, and how
many states we need.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Boris Zbarsky
In reply to this post by Jay Patel-3
Mike Beltzner wrote:
>  - publish the list of highly desired ones somewhere (wiki,
> dev.planning) where devs can see 'em

This runs into minor issues with the whole "security bugs" thing...  Though if
they're closed up anyway, maybe it's not a problem.  But this effectively gives
people a list of bug numbers to watch for checkins for...

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Rob Sayre-2
In reply to this post by Rob Sayre-2
L. David Baron wrote:
>
> Bugs that are absolute blockers for a release are very rare.
...
> For how many bugs would we delay a release ten years if they were
> the only serious problem with the release?  I think very few.
>

That's not a useful way to characterize the problem. The question we are
concerned with is: which bugs are worth delaying the release 1-2 weeks
instead of waiting 1.5-2 months for the next cycle.

> So if we want to have a useful state, it has to be something a
> little less rigorous.  The question is only how much less, and how
> many states we need.

I don't think the answer is a richer set of dropdowns. Based on what
I've read from release drivers, I think we should get rid of the blocker
keyword. Change it to "serious", and don't change the flag until after
the release. Ship without erasing the documentation.

-Rob
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Mike Beltzner
In reply to this post by Rob Sayre-2
> For how many bugs would we delay a release ten years if they were
> the only serious problem with the release?  I think very few.

That's why I was careful to say that there may always be exceptions to the rule, but for those exceptions the rationale should be: "what has changed between the point where we marked this as blocking and now that is making us change the blocking flag."

Excellent examples may include:

 - an assumption underlying the pending solution was proven false
 - the number of crash reports fell off, and it turns out this particular bug wasn't to blame
 - it's too important to hit the release window, and this one's dev-time estimate or regressions were too out of control
 - impending heat-death of universe required us to alter our release target
 - etc

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Chris Hofmann
In reply to this post by Myk Melez
Myk Melez wrote:

> Jay Patel wrote:
>> I agree that the way we use the "wanted" keyword is not ideal, since
>> it requires a log of flag setting/resetting... but it is working for
>> us right now.  If anyone has a better idea that will help us get
>> through these bugs quickly for each point release, which we try to
>> get done in 6-8 weeks from start to finish, please feel free to share.
>
> [FWIW, although I've been around for a while, I only recently joined
> drivers for the 2.0.0.2 release, so my comments may reflect that
> mixture of experience and inexperience.]
>
> I was confused about the blocking and wanted flags when I recently
> joined drivers for the 2.0.0.2 release, and although I've come to
> understand drivers' motivations for using them as they do, I share
> others' concerns about their ambiguity.
>
> It seems to me that there are four states a bug can be in for a branch:
>
> 1. Blocking the Next Release off the Branch (BNRB).  Using the most
> literal and specific sense of "block", the release won't happen until
> this bug gets fixed.
>
> 2. Critical for the Next Release off the Branch (CNRB).  This bug is
> critically important, and we don't want to ship the next release
> without it being fixed.  But if push comes to shove, and we don't have
> a fix for it, we would be willing to ship without it.
>
> 3. Wanted for the Branch (WB).  This bug should be fixed on the branch
> because it meets the branch criteria (topcrash, regression, security,
> low risk/high value polish, etc.).  But it's not important enough to
> warrant placement in either of the two previous categories.
>
> 4. Not Wanted for the Branch (NWB).  This bug does not meet the
> criteria for being fixed on the branch.
>
This is a pretty good list.

There is also at least one more state that is useful for helping to flag
bugs and drive to-do lists for creating a release.

That would be "Evaluation of this bug blocks the release, or Blocking
for Evaluation (BFE).  This marking would be for the series of bugs that
come in at the end game of the release, have the potential to be
regressions or serious problems, but a complete understanding of the
problem, or the scope and impact of the problem is not well understood.

We should continue to encourage these kind of  nominations and markings
at the end of release cycles to keep from making shipping mistakes.  
Having a list of these that can be driven helps to make sure we continue
to create great software.  Once the problem is better understood,
chances are that it might move to one of the more static categories
listed above.  These end game evaluations can often take multiple days.

Most of the categories list above (especially 2 and 3) seem to apply to
bugs that are known problems, with more of a history, that we attempt to
push hard on in an effort to get improvements shipped in the soonest
possible release.  Picking up a lot of  fixes in the second and third
category is what makes the big difference in improving Firefox in point
releases.  I think its important to remember that hard work on these
kind of fixes in during the development cycle and endgame is not wasted
-- it just gets to a better understanding of the problem and fix for the
next release.

> The problem I think we're running into is that we have no way to
> represent critical bugs, so we start a point release cycle by making
> them blocking, and we finish it by moving the ones that didn't get
> fixed into the wanted state.
>
> And that not only takes a bunch of triage time, it also confuses
> developers about how much those bugs actually matter.
>
> I know we've wanted some Bugzilla changes to make it easier for us to
> differentiate between these states, but until that happens, it seems
> like we could still significantly improve the situation today by
> adding one more flag per branch to represent critical bugs, f.e.
> critical1.8.1.x.
>
> Then drivers could mark bugs with their actual state, we wouldn't have
> to dance these bugs back and forth between states at various stages in
> the release cycle, and developers would understand what drivers
> actually thinks about the importance of the bugs.
>
> Notes:
>
> 1. We could use release-specific flags for the critical state (f.e.
> critical1.8.1.2), but that doesn't seem worth the effort required to
> retriage them at the end of each release, since they're almost certain
> to remain critical for the next release if they miss the current one.
>
> 2. A slight variation of this approach is for all
> blocking/critical/wanted bugs to be marked wanted, so a blocker has
> blocking+wanted flags, a critical bug has critical+wanted flags, and a
> wanted bug just has the wanted flag.  Not sure what makes more sense
> here.
>
> 3. This approach wouldn't mean a bug couldn't change states once
> triaged, of course.  It would continue to be possible for a blocker
> bug to be reevaluated down the road.  We just wouldn't be marking bugs
> as blockers to make them seem more important if we already know they
> would lose that status in a late-in-the-cycle reevaluation.
>
> 4. I realize that the schedule for minor releases is different from
> that for major releases, and we're less tolerant of schedule slip, so
> our criteria for blocking is stricter for minor releases than for
> major releases, yet we still want developers to take bugs targeted at
> minor releases seriously.
>
> But that doesn't seem to me to be a good reason to change the meaning
> of the term "blocking" for those releases.  Years ago we used to ship
> so-called "release candidates" that we knew we wouldn't ship as final
> releases because they were missing fixes that were blockers for the
> release.  We're the better for changing that policy so that we now
> only release true RCs, and I think we'd be better off fixing the way
> we use "blocker" so that we apply that term with similar rigor.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Christopher Aillon
In reply to this post by Rob Sayre-2
Robert Sayre wrote:

> L. David Baron wrote:
>>
>> Bugs that are absolute blockers for a release are very rare.
> ...
>> For how many bugs would we delay a release ten years if they were
>> the only serious problem with the release?  I think very few.
>>
>
> That's not a useful way to characterize the problem. The question we are
> concerned with is: which bugs are worth delaying the release 1-2 weeks
> instead of waiting 1.5-2 months for the next cycle.

The real question to ask is: why are cycles 1.5 to 2 months?  There's no
such thing as a true blocker bug for a date-driven release.  "Must
release by or around this date" is a fundamentally different philosophy
than "must have all these bugs fixed/features implemented".
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Gervase Markham
In reply to this post by Myk Melez
Myk Melez wrote:
> I know we've wanted some Bugzilla changes to make it easier for us to
> differentiate between these states, but until that happens, it seems
> like we could still significantly improve the situation today by adding
> one more flag per branch to represent critical bugs, f.e. critical1.8.1.x.

Are we not just reinventing Priority here?

The Priority field in Bugzilla is, as far as I can see, underused. It's
supposed to be used for prioritising bugs; no-one ever said that it
could only be used by the assignee.

How about saying that if a bug is marked as wanted, then the priority
gives the priority it's wanted with - P1 is a blocker (and perhaps we
could also set the blocker flag, although we wouldn't need it) - i.e.
BNRB, P2 is critical - CNRB, P3 is wanted - WB.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Michael Lefevre
On 2007-01-15, Gervase Markham <[hidden email]> wrote:
[snip]
> The Priority field in Bugzilla is, as far as I can see, underused. It's
> supposed to be used for prioritising bugs; no-one ever said that it
> could only be used by the assignee.

Actually it was my understanding that someone had said that - that the
priority was only to be set by the assignee, or someone who was in a
position to tell the assignee which bug to work on (i.e. their manager in
a company that was employing them). The wording of the bugzilla etiquette
document just says "have some say over the use of their time", and I guess
you could take it that drivers "have some say" over the use of everyone's
time.

I think caillon makes a good point - if releases are date driven rather
than bug driven, then you can't really have blockers as such.  If you're
aiming for a release on date X, then what you need is a list of bugs that
must be fixed by X date, and maybe a list of bugs that you hope will be
fixed by X date.

If you're not prepared to delay the release indefinitely (i.e. even if it
means shipping the x.x.x.1 release 3 years late) for a bug, then pretty
much no bug is going to be a "blocker", as dveditz said.  Which makes a
good case for not using the word "blocker", along with the fact that it's
got a history of different meanings attached to it within the project.

--
Michael
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Mike Beltzner
In reply to this post by Christopher Aillon
On 14-Jan-07, at 12:47 PM, Christopher Ailllon wrote:

> Robert Sayre wrote:
>> L. David Baron wrote:
>>>
>>> Bugs that are absolute blockers for a release are very rare.
>> ...
>>> For how many bugs would we delay a release ten years if they were
>>> the only serious problem with the release?  I think very few.
>>>
>> That's not a useful way to characterize the problem. The question  
>> we are concerned with is: which bugs are worth delaying the  
>> release 1-2 weeks instead of waiting 1.5-2 months for the next cycle.
>
> The real question to ask is: why are cycles 1.5 to 2 months?  
> There's no such thing as a true blocker bug for a date-driven  
> release.  "Must release by or around this date" is a fundamentally  
> different philosophy than "must have all these bugs fixed/features  
> implemented".

This is a bit of a straw man argument, and probably my fault as I was  
the first to bring the idea of "ship dates" into this discussion.  
There are, indeed, target release dates for every release, but Schrep  
puts it best when he says we're "quality driven" not date-driven. In  
that context, blockers absolutely make sense, but they must mean "the  
set of things without which we absolutely will not ship." We should  
aim to hit our targets, and continually adjust the set of things we  
expect to be able to ship in a release based on those targets, but  
also be willing to slip those targets if there are unresolved blockers.

I think it's more disingenuous to become more and more strict about  
what sort of bug becomes a blocker as we move through the release  
cycle, as opposed to maintaining a level of stringency and getting  
more used to figuring out a different way of marking a bug as  
"targeted for completion for this release," which is how I see the  
blocker list most often being used (and indeed how I initially used  
it until I witnessed how that can mess with people who have  
downstream dependencies).

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Christopher Aillon
Mike Beltzner wrote:

> On 14-Jan-07, at 12:47 PM, Christopher Ailllon wrote:
>
>> Robert Sayre wrote:
>>> L. David Baron wrote:
>>>>
>>>> Bugs that are absolute blockers for a release are very rare.
>>> ...
>>>> For how many bugs would we delay a release ten years if they were
>>>> the only serious problem with the release?  I think very few.
>>>>
>>> That's not a useful way to characterize the problem. The question we
>>> are concerned with is: which bugs are worth delaying the release 1-2
>>> weeks instead of waiting 1.5-2 months for the next cycle.
>>
>> The real question to ask is: why are cycles 1.5 to 2 months?  There's
>> no such thing as a true blocker bug for a date-driven release.  "Must
>> release by or around this date" is a fundamentally different
>> philosophy than "must have all these bugs fixed/features implemented".
>
> This is a bit of a straw man argument, and probably my fault as I was
> the first to bring the idea of "ship dates" into this discussion. There
> are, indeed, target release dates for every release, but Schrep puts it
> best when he says we're "quality driven" not date-driven.

You'd be hard pressed to find a software project that would claim they
weren't quality driven.

Note: I'm not saying the "release early, release often" strategy is bad
nor am I really questioning it, just calling it what it is in an effort
to explain to Robert why "blocker" bugs currently aren't treated the way
the people think they should be.  All I'm saying is that if we have a
desire to ship every 4-6 weeks, it becomes a lot harder to call some
bugs blockers because A) we have a ship window that we want to hit and
B) there will be another release in 4-6 weeks we can get the fixes into.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Myk Melez
In reply to this post by Christopher Aillon
Mike Beltzner wrote:

>> Robert Sayre wrote:
>> The real question to ask is: why are cycles 1.5 to 2 months?  There's
>> no such thing as a true blocker bug for a date-driven release.  "Must
>> release by or around this date" is a fundamentally different
>> philosophy than "must have all these bugs fixed/features implemented".
>
> This is a bit of a straw man argument, and probably my fault as I was
> the first to bring the idea of "ship dates" into this discussion. There
> are, indeed, target release dates for every release, but Schrep puts it
> best when he says we're "quality driven" not date-driven.

That's true for major releases (which are primarily quality and feature
driven, although timing also plays a role), but minor releases are
largely date-driven, since we ship them on a mostly regular schedule,
and very few of the bugs we target at them actually block their release.

As I recall, we decided to do minor releases this way to better allocate
scarce build and release resources.  Regularly-scheduled minor releases
may also have the beneficial side-effect of being more tolerable to our
users.

And since major releases already meet our quality standards, minor
releases generally cross no significant quality threshold, so there is
no urgent quality-based reason to release them at any particular time.

Except for serious security bugs, of course, for which we do expedite
minor releases.


> In that
> context, blockers absolutely make sense, but they must mean "the set of
> things without which we absolutely will not ship." We should aim to hit
> our targets, and continually adjust the set of things we expect to be
> able to ship in a release based on those targets, but also be willing to
> slip those targets if there are unresolved blockers.

Right, and this is true even for largely date-driven releases.  The
number of blockers is just much lower in them.

-myk
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: blockers should...

Myk Melez
In reply to this post by Gervase Markham
Gervase Markham wrote:
> Are we not just reinventing Priority here?

Somewhat (or else Severity, the field with a "blocker" option).  But
we're flagging bugs for multiple releases, and bugs may have different
priorities/severities in the different releases.


> The Priority field in Bugzilla is, as far as I can see, underused. It's
> supposed to be used for prioritising bugs; no-one ever said that it
> could only be used by the assignee.

The "blocker" severity used to mean that the bug was blocking testing of
nightly builds, and the tree was closed until all nightly blockers were
fixed.  The field may indeed be underused, but I'd say there's still
value in keeping it for those engineers who do use it.

-myk
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12