IMPORTANT: Triage on P3 bugs for GlassFish V2/9.1

[Dhiru Pandey]

Hello GlassFish Developers,

We are almost done with GlassFish V2/9.1 Beta. Thanks again to all of you for making this possible.

Now its time to focus on FCS for this release - in particular fixing P3 bugs required for FCS.

We have too many P3 bugs currently:

P3 bugs on Issue Tracker (436 currently)
P3 bugs on Bugster (468 currently)

We need to do a triage on these bugs and decide which of these bugs must be fixed for FCS. Currently, there may be bugs that are classified as P3 bugs which may not be required for this release or may be some corner case that has been misclassified as a P3, etc. We need to separate these bugs out.

In working towards that goal, please evaluate your P3 bugs and mark all those bugs that absolutely need to be fixed by FCS by doing the following:

On Issue Tracker - Please add the keyword as91-fcs in the Status whiteboard field for all such P3 bugs
On Bugster - Please add the keyword as91-fcs in Hook6 field for all such P3 bugs. Please ensure that all P3 bugs that are S1 (severity 1) are marked by adding this keyword to Hook6 field

Please work towards getting this done by COB 2/16/2007

Thanks,

-Dhiru & Sridatta

[Bill Shannon]

Wrong, wrong, wrong.

I see it's time for me to yet again explain how we are supposed to use
bug priorities.  Haven't I done this at least every release for the
past, oh, I don't know, 8 years?

A bug doesn't have an inherent priority.  A bug isn't born with a priority.
The priority of a bug is *our* decision.  Not just a technical decision.
Not just based on the impact of the bug.  Not just based on the severity of
the bug.  But also based on resource, business decisions, and so on.

The priority of a bug is the *output* of our decision making process;
it reflects what we *decided*, not what a bug *is*.

If we think a bug absolutely, positively, *MUST* be fixed before FCS,
and if that one single bug is not fixed before FCS we will absolutely
hold up the release until that single bug is fixed, then we mark it as
a P3.  Similarly for beta, we mark it as a P2.  You can probably guess
how important a P1 bug is.

If we just *want* to fix the bug for FCS, that's a P4 bug.

If you have a P4 bug, and you want to fix it for FCS, but you don't want
to lose track of it, fill in the "target release" field with the name of
the release where you intend to fix it.

And if there are P4 bugs that you're not expecting to get to anytime
soon, well, that's why we have P5.

Do not add keywords to the bugs.

This is the way we manage 900 bugs.  We divide them into categories that
are manageable.  The bugs that deserve the bulk of our attention are
those that we absolutely have to fix no matter what.  If there aren't
many less than 900 of those bugs, we're in deep trouble.

Remember that when you submit a bug.  Remember that when you assign a
bug.  Remember that when you evaluate a bug.  If we aren't constantly
verifying that bug priorities are correct, we'll end up with an
unmanageable mess of thousands of bugs.


Oh, and those bug queries, they're not including all the components
that feed into GlassFish.  We need to count them as well.



Dhiru Pandey wrote:

> Hello GlassFish Developers,
>
> We are almost done with GlassFish V2/9.1 Beta. Thanks again to all of
> you for making this possible.
>
> Now its time to focus on FCS for this release - in particular fixing P3
> bugs required for FCS.
>
> We have too many P3 bugs currently:
>
> P3 bugs on *Issue Tracker* (436 currently)
> <https://glassfish.dev.java.net/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=glassfish&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&priority=P3&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&field0-0-0=reporter&type0-0-0=notequals&value0-0-0=gfbugbridge&field1-0-0=status_whiteboard&type1-0-0=notequals&value1-0-0=as91-na&field2-0-0=subcomponent&type2-0-0=notequals&value2-0-0=sqe-test&cmdtype=doit&namedcmd=All+JDBC%2FJMS%2FJCA+bugs&newqueryname=&or 
> der=Reuse+same+sort+as+last+time>
> P3 bugs on *Bugster* (468 currently)
> <http://monaco.sfbay/list.jsf?product=sunone_application_server&hook4Opt=2&hook5Opt=2&area=Defect&CRrelease=null%2C9*&hook5=82to91-fp-na&hook4=as91-na%2Cas91-fixed%2Cas91-beta-waived&hook3=sjsmq-issues&title=Open+Bugs+with+Target+Release+9*%2C+null&hook2=as9-na&subcategory=bugbridge_test,docs,proxy_plugin,sample_apps,test_sqe&priority=3&sbOpt=2¬Subcategory=on&sb=glassfish-bugbridge%40sun.com&lh=1&hook2Opt=2&hook3Opt=2&fields=7.-.-.7,4.a.l.20&fieldids=59,7,36,4,51,54,1,76,90>
>
> We need to do a triage on these bugs and decide which of these bugs must
> be fixed for FCS. Currently, there may be bugs that are classified as P3
> bugs which may not be required for this release or may be some corner
> case that has been misclassified as a P3, etc. We need to separate these
> bugs out.
>
> In working towards that goal, please evaluate your P3 bugs and mark all
> those bugs that *absolutely need to be fixed by FCS* by doing the following:
>
> *On Issue Tracker* - Please add the keyword *as91-fcs* in the Status
> whiteboard field for all such P3 bugs
> *On Bugster* - Please add the keyword *as91-fcs* in Hook6 field for all
> such P3 bugs. Please ensure that all P3 bugs that are S1 (severity 1)
> are marked by adding this keyword to Hook6 field
>
> Please work towards getting this done by *COB 2/16/2007*
>
> Thanks,
>
> -Dhiru & Sridatta

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gustav Trede]

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.

best regards
  gustav trede

Dhiru Pandey wrote:

> Hello GlassFish Developers,
>
> We are almost done with GlassFish V2/9.1 Beta. Thanks again to all of
> you for making this possible.
>
> Now its time to focus on FCS for this release - in particular fixing
> P3 bugs required for FCS.
>
> We have too many P3 bugs currently:
>
> P3 bugs on *Issue Tracker* (436 currently)
> <https://glassfish.dev.java.net/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=glassfish&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&priority=P3&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&field0-0-0=reporter&type0-0-0=notequals&value0-0-0=gfbugbridge&field1-0-0=status_whiteboard&type1-0-0=notequals&value1-0-0=as91-na&field2-0-0=subcomponent&type2-0-0=notequals&value2-0-0=sqe-test&cmdtype=doit&namedcmd=All+JDBC%2FJMS%2FJCA+bugs&newqueryname=&or%0Ader=Reuse+same+sort+as+last+time>
> P3 bugs on *Bugster* (468 currently)
> <http://monaco.sfbay/list.jsf?product=sunone_application_server&hook4Opt=2&hook5Opt=2&area=Defect&CRrelease=null%2C9*&hook5=82to91-fp-na&hook4=as91-na%2Cas91-fixed%2Cas91-beta-waived&hook3=sjsmq-issues&title=Open+Bugs+with+Target+Release+9*%2C+null&hook2=as9-na&subcategory=bugbridge_test,docs,proxy_plugin,sample_apps,test_sqe&priority=3&sbOpt=2¬Subcategory=on&sb=glassfish-bugbridge%40sun.com&lh=1&hook2Opt=2&hook3Opt=2&fields=7.-.-.7,4.a.l.20&fieldids=59,7,36,4,51,54,1,76,90>
>
> We need to do a triage on these bugs and decide which of these bugs
> must be fixed for FCS. Currently, there may be bugs that are
> classified as P3 bugs which may not be required for this release or
> may be some corner case that has been misclassified as a P3, etc. We
> need to separate these bugs out.
>
> In working towards that goal, please evaluate your P3 bugs and mark
> all those bugs that *absolutely need to be fixed by FCS* by doing the
> following:
>
> *On Issue Tracker* - Please add the keyword *as91-fcs* in the Status
> whiteboard field for all such P3 bugs
> *On Bugster* - Please add the keyword *as91-fcs* in Hook6 field for
> all such P3 bugs. Please ensure that all P3 bugs that are S1 (severity
> 1) are marked by adding this keyword to Hook6 field
>
> Please work towards getting this done by *COB 2/16/2007*
>
> Thanks,
>
> -Dhiru & Sridatta

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[vince kraemer]

I cc'ed the quality alias, since this is a pretty relevant discussion
for that alias.

Bill Shannon wrote:
> Wrong, wrong, wrong.
>
> I see it's time for me to yet again explain how we are supposed to use
> bug priorities.  Haven't I done this at least every release for the
> past, oh, I don't know, 8 years?
>
> A bug doesn't have an inherent priority.  A bug isn't born with a
> priority.

I thought issues are created with a priority value by the filer....
> The priority of a bug is *our* decision.  Not just a technical decision.
> Not just based on the impact of the bug.  Not just based on the
> severity of
> the bug.  But also based on resource, business decisions, and so on.

A filer doesn't have visibility into these factors, so should all bugs
get filed as P1/unconfirmed?

This would basically mean that the bug must get evaluated and assigned a
priority, before the product can ship?
>
> The priority of a bug is the *output* of our decision making process;
> it reflects what we *decided*, not what a bug *is*.
>
> If we think a bug absolutely, positively, *MUST* be fixed before FCS,
> and if that one single bug is not fixed before FCS we will absolutely
> hold up the release until that single bug is fixed, then we mark it as
> a P3.  Similarly for beta, we mark it as a P2.  You can probably guess
> how important a P1 bug is.

Fix before next promoted build?
>
> If we just *want* to fix the bug for FCS, that's a P4 bug.
>
> If you have a P4 bug, and you want to fix it for FCS, but you don't want
> to lose track of it, fill in the "target release" field with the name of
> the release where you intend to fix it.
>
> And if there are P4 bugs that you're not expecting to get to anytime
> soon, well, that's why we have P5.

I think this is a reasonable "process"... It is a bit different than the
processes that the help associated with the GF issue tracker presents.
We may want to publish an outline of the process on the wiki for the
community, so filers do not misunderstand the meaning of their P2 bug
being reclassified as a P4 bug...
>
> Do not add keywords to the bugs.
>
> This is the way we manage 900 bugs.  We divide them into categories that
> are manageable.  The bugs that deserve the bulk of our attention are
> those that we absolutely have to fix no matter what.  If there aren't
> many less than 900 of those bugs, we're in deep trouble.
>
> Remember that when you submit a bug.  

It is very hard for filers to assign priorities.  That is really the
"job" of the person that evaluates the bug.

But, that really means that all bugs that are unconfirmed need to be
treated as high priority issue until they have been evaluated...

For example; in the GF issue tracker there are 375 unconfirmed issues,
291 of them are DEFECTS...

As a person evaluating products based on the GF codebase, this is a very
troubling issue.

To me, at first glance, it looks like there are 291 possible show
stopper issues that haven't been examined.

I know that that isn't exactly true, since I am pretty tied into the
community...  Other folks aren't and won't be able to invest the time

vbk

> Remember that when you assign a
> bug.  Remember that when you evaluate a bug.  If we aren't constantly
> verifying that bug priorities are correct, we'll end up with an
> unmanageable mess of thousands of bugs.
>
>
> Oh, and those bug queries, they're not including all the components
> that feed into GlassFish.  We need to count them as well.
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dhiru Pandey]

Thanks for explaining this once again :-)
We are in agreement with the bug prioritization process outlined by you.

As explained in our hallway conversation, our intention in using the
keyword was to simply get a head start with a quick initial list of P3
bugs that get worked on before the rest of the P3s.

We will work towards coming up with a bug prioritization process that
will be based on your feedback and others in the community.
We will also need to ensure that this process works for GlassFish
open-source community.

This will be published and sent out as soon as possible.

Thanks,
-Dhiru & Sridatta

Bill Shannon wrote:

> Wrong, wrong, wrong.
>
> I see it's time for me to yet again explain how we are supposed to use
> bug priorities.  Haven't I done this at least every release for the
> past, oh, I don't know, 8 years?
>
> A bug doesn't have an inherent priority.  A bug isn't born with a
> priority.
> The priority of a bug is *our* decision.  Not just a technical decision.
> Not just based on the impact of the bug.  Not just based on the
> severity of
> the bug.  But also based on resource, business decisions, and so on.
>
> The priority of a bug is the *output* of our decision making process;
> it reflects what we *decided*, not what a bug *is*.
>
> If we think a bug absolutely, positively, *MUST* be fixed before FCS,
> and if that one single bug is not fixed before FCS we will absolutely
> hold up the release until that single bug is fixed, then we mark it as
> a P3.  Similarly for beta, we mark it as a P2.  You can probably guess
> how important a P1 bug is.
>
> If we just *want* to fix the bug for FCS, that's a P4 bug.
>
> If you have a P4 bug, and you want to fix it for FCS, but you don't want
> to lose track of it, fill in the "target release" field with the name of
> the release where you intend to fix it.
>
> And if there are P4 bugs that you're not expecting to get to anytime
> soon, well, that's why we have P5.
>
> Do not add keywords to the bugs.
>
> This is the way we manage 900 bugs.  We divide them into categories that
> are manageable.  The bugs that deserve the bulk of our attention are
> those that we absolutely have to fix no matter what.  If there aren't
> many less than 900 of those bugs, we're in deep trouble.
>
> Remember that when you submit a bug.  Remember that when you assign a
> bug.  Remember that when you evaluate a bug.  If we aren't constantly
> verifying that bug priorities are correct, we'll end up with an
> unmanageable mess of thousands of bugs.
>
>
> Oh, and those bug queries, they're not including all the components
> that feed into GlassFish.  We need to count them as well.
>
>
>
> Dhiru Pandey wrote:
>> Hello GlassFish Developers,
>>
>> We are almost done with GlassFish V2/9.1 Beta. Thanks again to all of
>> you for making this possible.
>>
>> Now its time to focus on FCS for this release - in particular fixing
>> P3 bugs required for FCS.
>>
>> We have too many P3 bugs currently:
>>
>> P3 bugs on *Issue Tracker* (436 currently)
>> <https://glassfish.dev.java.net/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=glassfish&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&priority=P3&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&field0-0-0=reporter&type0-0-0=notequals&value0-0-0=gfbugbridge&field1-0-0=status_whiteboard&type1-0-0=notequals&value1-0-0=as91-na&field2-0-0=subcomponent&type2-0-0=notequals&value2-0-0=sqe-test&cmdtype=doit&namedcmd=All+JDBC%2FJMS%2FJCA+bugs&newqueryname=&or 
>> der=Reuse+same+sort+as+last+time>
>> P3 bugs on *Bugster* (468 currently)
>> <http://monaco.sfbay/list.jsf?product=sunone_application_server&hook4Opt=2&hook5Opt=2&area=Defect&CRrelease=null%2C9*&hook5=82to91-fp-na&hook4=as91-na%2Cas91-fixed%2Cas91-beta-waived&hook3=sjsmq-issues&title=Open+Bugs+with+Target+Release+9*%2C+null&hook2=as9-na&subcategory=bugbridge_test,docs,proxy_plugin,sample_apps,test_sqe&priority=3&sbOpt=2¬Subcategory=on&sb=glassfish-bugbridge%40sun.com&lh=1&hook2Opt=2&hook3Opt=2&fields=7.-.-.7,4.a.l.20&fieldids=59,7,36,4,51,54,1,76,90>
>>
>>
>> We need to do a triage on these bugs and decide which of these bugs
>> must be fixed for FCS. Currently, there may be bugs that are
>> classified as P3 bugs which may not be required for this release or
>> may be some corner case that has been misclassified as a P3, etc. We
>> need to separate these bugs out.
>>
>> In working towards that goal, please evaluate your P3 bugs and mark
>> all those bugs that *absolutely need to be fixed by FCS* by doing the
>> following:
>>
>> *On Issue Tracker* - Please add the keyword *as91-fcs* in the Status
>> whiteboard field for all such P3 bugs
>> *On Bugster* - Please add the keyword *as91-fcs* in Hook6 field for
>> all such P3 bugs. Please ensure that all P3 bugs that are S1
>> (severity 1) are marked by adding this keyword to Hook6 field
>>
>> Please work towards getting this done by *COB 2/16/2007*
>>
>> Thanks,
>>
>> -Dhiru & Sridatta
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dhiru Pandey]

Hi,

I am not sure where you got the idea that target ship date will take
priority over everything else.

We will slip the target FCS date if we find that we have bugs that
compromise quality and need to be fixed.
We will however continue to set priorities for all bugs based on
functional requirments, resources and other business/marketing decisions.
Naturally, some of the bugs will not be fixed based on their priority.
But that does not mean that we will sacrifice overall quality of the
product.

If you feel that some bug/issue has been incorrectly prioritized :
- Please send us e-mail, we will be happy to help with the bug
OR
- Re-prioritize the bug with the appropriate justification - we will
re-evaluate that

Best Regards,
-Dhiru

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.
>
> best regards
>  gustav trede
>
> Dhiru Pandey wrote:
>> Hello GlassFish Developers,
>>
>> We are almost done with GlassFish V2/9.1 Beta. Thanks again to all of
>> you for making this possible.
>>
>> Now its time to focus on FCS for this release - in particular fixing
>> P3 bugs required for FCS.
>>
>> We have too many P3 bugs currently:
>>
>> P3 bugs on *Issue Tracker* (436 currently)
>> <https://glassfish.dev.java.net/issues/buglist.cgi?Submit+query=Submit+query&issue_type=DEFECT&component=glassfish&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&priority=P3&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&field0-0-0=reporter&type0-0-0=notequals&value0-0-0=gfbugbridge&field1-0-0=status_whiteboard&type1-0-0=notequals&value1-0-0=as91-na&field2-0-0=subcomponent&type2-0-0=notequals&value2-0-0=sqe-test&cmdtype=doit&namedcmd=All+JDBC%2FJMS%2FJCA+bugs&newqueryname=&or%0Ader=Reuse+same+sort+as+last+time>
>>
>> P3 bugs on *Bugster* (468 currently)
>> <http://monaco.sfbay/list.jsf?product=sunone_application_server&hook4Opt=2&hook5Opt=2&area=Defect&CRrelease=null%2C9*&hook5=82to91-fp-na&hook4=as91-na%2Cas91-fixed%2Cas91-beta-waived&hook3=sjsmq-issues&title=Open+Bugs+with+Target+Release+9*%2C+null&hook2=as9-na&subcategory=bugbridge_test,docs,proxy_plugin,sample_apps,test_sqe&priority=3&sbOpt=2¬Subcategory=on&sb=glassfish-bugbridge%40sun.com&lh=1&hook2Opt=2&hook3Opt=2&fields=7.-.-.7,4.a.l.20&fieldids=59,7,36,4,51,54,1,76,90>
>>
>>
>> We need to do a triage on these bugs and decide which of these bugs
>> must be fixed for FCS. Currently, there may be bugs that are
>> classified as P3 bugs which may not be required for this release or
>> may be some corner case that has been misclassified as a P3, etc. We
>> need to separate these bugs out.
>>
>> In working towards that goal, please evaluate your P3 bugs and mark
>> all those bugs that *absolutely need to be fixed by FCS* by doing the
>> following:
>>
>> *On Issue Tracker* - Please add the keyword *as91-fcs* in the Status
>> whiteboard field for all such P3 bugs
>> *On Bugster* - Please add the keyword *as91-fcs* in Hook6 field for
>> all such P3 bugs. Please ensure that all P3 bugs that are S1
>> (severity 1) are marked by adding this keyword to Hook6 field
>>
>> Please work towards getting this done by *COB 2/16/2007*
>>
>> Thanks,
>>
>> -Dhiru & Sridatta
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bill Shannon]

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bill Shannon]

vince kraemer wrote:

> I cc'ed the quality alias, since this is a pretty relevant discussion
> for that alias.
>
> Bill Shannon wrote:
>> Wrong, wrong, wrong.
>>
>> I see it's time for me to yet again explain how we are supposed to use
>> bug priorities.  Haven't I done this at least every release for the
>> past, oh, I don't know, 8 years?
>>
>> A bug doesn't have an inherent priority.  A bug isn't born with a
>> priority.
>
> I thought issues are created with a priority value by the filer....

Initially we considered having a separate field for the submitter
to suggest how important the bug was, and require the owner of the
bug to choose the priority based on the submitter's input and other
factors, but that just seemed unnecessarily complex.  So the submitter
gets to suggest how important the bug is when they file it, but it's
up to the owner of the bug to adjust the priority as appropriate.

My point is that priority is a measure of a bug's importance at a
point in time, and it can change over time.  It's not something
inherent to the bug.

>> The priority of a bug is *our* decision.  Not just a technical decision.
>> Not just based on the impact of the bug.  Not just based on the
>> severity of
>> the bug.  But also based on resource, business decisions, and so on.
>
> A filer doesn't have visibility into these factors, so should all bugs
> get filed as P1/unconfirmed?
>
> This would basically mean that the bug must get evaluated and assigned a
> priority, before the product can ship?

See above.  The submitter suggests an initial priority.  The owner of
the bug should always be evaluating the bug to determine whether that
suggestion is appropriate or not.

>> The priority of a bug is the *output* of our decision making process;
>> it reflects what we *decided*, not what a bug *is*.
>>
>> If we think a bug absolutely, positively, *MUST* be fixed before FCS,
>> and if that one single bug is not fixed before FCS we will absolutely
>> hold up the release until that single bug is fixed, then we mark it as
>> a P3.  Similarly for beta, we mark it as a P2.  You can probably guess
>> how important a P1 bug is.
>
> Fix before next promoted build?

If not sooner.  Generally it means "drop everything and work on this".

>> If we just *want* to fix the bug for FCS, that's a P4 bug.
>>
>> If you have a P4 bug, and you want to fix it for FCS, but you don't want
>> to lose track of it, fill in the "target release" field with the name of
>> the release where you intend to fix it.
>>
>> And if there are P4 bugs that you're not expecting to get to anytime
>> soon, well, that's why we have P5.
>
> I think this is a reasonable "process"... It is a bit different than the
> processes that the help associated with the GF issue tracker presents.
> We may want to publish an outline of the process on the wiki for the
> community, so filers do not misunderstand the meaning of their P2 bug
> being reclassified as a P4 bug...

Yes.  I thought this was raised and dealt with a year ago when we really
started using Issue Tracker.  The process I've described is the process
we're supposed to be using within Sun for Bugtraq.

>> Do not add keywords to the bugs.
>>
>> This is the way we manage 900 bugs.  We divide them into categories that
>> are manageable.  The bugs that deserve the bulk of our attention are
>> those that we absolutely have to fix no matter what.  If there aren't
>> many less than 900 of those bugs, we're in deep trouble.
>>
>> Remember that when you submit a bug.  
>
> It is very hard for filers to assign priorities.  That is really the
> "job" of the person that evaluates the bug.
>
> But, that really means that all bugs that are unconfirmed need to be
> treated as high priority issue until they have been evaluated...

That's why Bugtraq has "dispatched" and "accepted" states.  Until a
bug moves from dispatched to accepted, you shouldn't trust the priority.
Which is why bugs should remain in the dispatched state for as little
time as possible, preferably less than a week.

Issue Tracker doesn't match our process as well so I'm not sure exactly
how this should map.

> For example; in the GF issue tracker there are 375 unconfirmed issues,
> 291 of them are DEFECTS...
>
> As a person evaluating products based on the GF codebase, this is a very
> troubling issue.
>
> To me, at first glance, it looks like there are 291 possible show
> stopper issues that haven't been examined.

If there are 291 issues that no one has looked into even enough to
know whether the priorities seem correct, you should be worried.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Gustav Trede]

 Bill Shannon , thanks for clarifying.

Im glad this project is developed in a more healthier environment then
jdk 1.6 was.
Still no eta on several disaster bugs regarding webstart etc, that imo
should have been FCS stoppers.

The open line of communication in the glassfish project is astonishing
and healthy.

Glassfish is progressing so fast that it in reality might not matter so
much regarding a few skipped bugs at deadline.
As long as external projects like netbeans that tend to base bundles on
releases works, all should be ok.

regards
  gustav trede

> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jim Driscoll]

Gustav Trede wrote:
> The open line of communication in the glassfish project is astonishing
> and healthy.

Thank you!!

Jim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jim Driscoll]

Bill Shannon wrote:
> vince kraemer wrote:
>> But, that really means that all bugs that are unconfirmed need to be
>> treated as high priority issue until they have been evaluated...
>
> That's why Bugtraq has "dispatched" and "accepted" states.  Until a
> bug moves from dispatched to accepted, you shouldn't trust the priority.
> Which is why bugs should remain in the dispatched state for as little
> time as possible, preferably less than a week.

It's worth mentioning that one of our release criteria is that we
evaluate all our bugs before shipping.  Certainly, this is what my part
of the Glassfish team does.

Jim

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...