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_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
>