Re: What if "blocker" meant "blocker"?

[Elijah Newren <newren gmail com>]

<warning type="somewhat rambling response" />

Hi,

On 1/6/06, Ryan Lortie <desrt desrt ca> wrote:
> Hello Release Team.
>
> For next release cycle, I have a simple suggestion to improve the
> release process:
>
> Don't release software with major bugs in it.

Thanks for bringing this up.  I agree that blocker bugs (meaning the
"gnome-target" field, not severity=blocker bugs) don't get the
attention they deserve, and that we need to do more work on changing
that.

> It might make sense for the next release cycle to have a longer hard
> code freeze (2, maybe even 3 weeks) during which developers are
> encouraged to work on bugs on the blocker list.

The last time we tried a 2 week hard code freeze it was one of the
only things that people commented on when we asked for feedback -- and
they requested that we remove it and return to a 1 week hard code
freeze.  Besides, I'd like to start a lot sooner than that on these
bugs.

<snip>
> The delay is merely following the natural definition of "blocker".

One of the problems (more below) is that there are a lot of the bugs
on those lists (the majority of them, every time I've ever looked at
the list) that don't merit the term "blocker".  That's not something
that's easy to fix.  Rather than run the risk of overlooking bugs that
we shouldn't, we've instead decided to say that anyone can nominate a
bug for the blocker list by just setting the "Gnome Target" field on
it.  But it means that we need people being proactive at kicking ones
off the list that don't belong there.  It also makes it more important
to have ways of making the bugs more prominent in general or they get
drowned out...

There is a related issue in that there are a lot of bugs that don't
merit the term "blocker" but would nevertheless be great to provide
extra prominence to.  Lots of those.  We don't have a good way of
doing that, so I've often just slacked a little at kicking bugs off
the list that weren't true blockers.  If we do start being strict on
the meaning, then we might lose out on getting other
not-quite-as-important-but-still-nasty bugs getting fixed.

> When you can go on Bugzilla right now and see "Blocker bugs:
> GNOME 2.12.x (these must be fixed before/in the specified GNOME
> version)" with a list of open bugs under it something is wrong.

It looks like the 2.10 list isn't yet even clean, though luckily it
looks like people have mostly cleaned out the 2.6-2.10 lists.

Anyway, note that those lists were added by Olav in response to the
fact that "blocker" bugs weren't getting much attention due to being a
pain to find and not being very visible.  The old way to find them was
to either be really proactive about querying (which some people do,
but there were zillions of things to be proactive in querying for),
or, more likely, wait for someone from the bugsquad to come up with a
query (which naturally found all blockers in all products) mail the
query to d-d-l and hope that developers happened to take a look at
that query often and search for bugs that might be against their
products if there were any -- and then if there were wade through
those bugs to see if they really merited attention.  It just didn't
scale or work well.

We've also done nagging lists in the past.  I've done a few, talked
Vincent (Noel) and Olav into doing one or two, and Luis and I think
Andrew have done some.  But, it takes some time to summarize all the
bugs appropriately.  No one had the time to do so last release cycle
until Olav brought up the issue just before hard code freeze.  That
didn't leave a lot of time to fix all of them, though it still did
make things much better for us when he made a summarized list for us.


So, what we need more than anything is people willing to go over these
lists of bugs, summarize the issues, the state of the bug, and other
pertinent information, and email regularly (every two weeks or so?)
starting earlier in the cycle leading up to the release.  If that were
to happen, then we'd be in a lot better position to slip the release
if important issues still weren't fixed despite their prominence and
would likely make people pay more attention to the lists in the
future.


Anyway, enough of my rambling...