dev@glassfish.java.net

Re: IMPORTANT: Triage on P3 bugs for GlassFish V2/9.1

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Thu, 15 Feb 2007 21:36:12 -0800

Gustav Trede wrote:
> Hello,
>
> So there is no goal for actual FCS quality ?
>
> By letting the target date take priority over everything else and
> move enough bugs to P4 just for the sake of a dead line is ....
>
> Pretending that the quality part of a deadline is something less
> important then the date part just because the quality is a less
> absolute , harder to quantify
> and its easy to hide on paper is that a way that make you feel good and
> proud as a software engineer?.
>
> Perhaps its the FCS date that is too narrow and not the P3 bugs that are
> too many ?
> It scares me that you believe that the solution for this problem is one
> sided only.
>
> So why do you have 2 parameters for FCS ? the date is the only part that
> is the real target anyhow.

Of course quality is important, but I think you misunderstand how we
use priority. Priority does not directly measure quality. Priority
reflects our decision about the importance of a bug, given its severity
(which *is* directly related to quality) and other factors.

No matter what, there are some bugs that we're going to choose to fix
before FCS and some bugs that we're not going to fix before FCS.
Adjusting the priority of the bug reflects that decision and makes it
clear to everyone what we're deciding. We could instead keep a "side
list" of what we think is important and what we don't think is important
and just leave priority alone. But that would be much less transparent.

Like it or not, date *is* important, and not every bug that's submitted
as a P3 is going to be fixed before we ship. The only issue here is how
we're going to reflect that decision in an open and transparent way.
The way we've chosen to do that is by adjusting the priority of the bug.

We could have a discussion as to whether releases should be date driven
or quality driven, but that's a different subject. It's often the case
that a "good enough" product "now" is better than a "very good" product
"later". Still, if you think the overall quality is less than "good
enough", we should reevaluate our date.