I've noticed lately that when I view bug reports on Sunsolve, all
of the comments have been deleted. There's only the one-line
synopsis and a one-word resolution. This makes it virtually
impossible for me to determine if a problem that I'm experiencing
is the result of a known bug. The only way to find out is to open
a case. This is a waste of everybody's time.


--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

Gary Mills <mills@cc.umanitoba.ca> wrote:
> I've noticed lately that when I view bug reports on Sunsolve, all
> of the comments have been deleted. There's only the one-line
> synopsis and a one-word resolution. This makes it virtually
> impossible for me to determine if a problem that I'm experiencing
> is the result of a known bug. The only way to find out is to open
> a case. This is a waste of everybody's time.

It is, but there is something being done about it.

Not all of the fields in a bug report are available to the public - some
are private due to proprietary information, customer details, etc.

Historically it's been fairly common to put the majority of the details
in these hidden fields ("comments" being the one you'll normally see
mentioned), but the policy now is that wherever possible all details
should be put in public fields, and only stuff which absolutely can't be
made public (eg, customer details) should be put in the private fields.

There's not much can be done about this for old bugs, but hopefully in
the future it won't be as big a problem.

Got a specific bug you're interested in? I'm sure someone here will be
able to give you some more details on it.

Scott

In <1130235476.519142@docbert> Scott Howard <scott@hunterlink.net.au> writes:

>Gary Mills <mills@cc.umanitoba.ca> wrote:
>> I've noticed lately that when I view bug reports on Sunsolve, all
>> of the comments have been deleted. There's only the one-line
>> synopsis and a one-word resolution. This makes it virtually
>> impossible for me to determine if a problem that I'm experiencing
>> is the result of a known bug. The only way to find out is to open
>> a case. This is a waste of everybody's time.

>It is, but there is something being done about it.

That's good to hear.

>Got a specific bug you're interested in? I'm sure someone here will be
>able to give you some more details on it.

Yes, I was checking on 6322616, which is quite a recent one. The
synopsis says something about `boot time regression'. I can't guess
what that really means. The fix for that apparently broke a feature
of smpatch in Solaris 10.

--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

Gary Mills <mills@cc.umanitoba.ca> writes:
> >Got a specific bug you're interested in? I'm sure someone here will be
> >able to give you some more details on it.
>
> Yes, I was checking on 6322616, which is quite a recent one. The
> synopsis says something about `boot time regression'. I can't guess
> what that really means. The fix for that apparently broke a feature
> of smpatch in Solaris 10.

"Boot time regression" means that the system boots up more slowly (in
this case, by 11.48%, according to the synopsis). (There's a standard
internal performance test called "boot time," hence any slow down in
booting time is a regression in that test.)

We measure and care about this because folks who calculate
availability numbers use boot time as part of the metrics.

--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

In article <xoavoe5defoz.fsf@sun.com>,
James Carlson <james.d.carlson@sun.com> writes:
> Gary Mills <mills@cc.umanitoba.ca> writes:
>> >Got a specific bug you're interested in? I'm sure someone here will be
>> >able to give you some more details on it.
>>
>> Yes, I was checking on 6322616, which is quite a recent one. The
>> synopsis says something about `boot time regression'. I can't guess
>> what that really means. The fix for that apparently broke a feature
>> of smpatch in Solaris 10.
>
> "Boot time regression" means that the system boots up more slowly (in
> this case, by 11.48%, according to the synopsis). (There's a standard
> internal performance test called "boot time," hence any slow down in
> booting time is a regression in that test.)
>
> We measure and care about this because folks who calculate
> availability numbers use boot time as part of the metrics.

I'm guessing that PROM diagnostics and such don't count, because they seem
to take quite a bit longer than the actual boot on some of the larger
systems.


--
mailto:rlhamil@smart.net http://www.smart.net/~rlhamil

Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"

Richard.L.Hamilton@mindwarp.smart.net (Richard L. Hamilton) writes:

>I'm guessing that PROM diagnostics and such don't count, because they seem
>to take quite a bit longer than the actual boot on some of the larger
>systems.

They are taken into account; but because they're fixed in time, they
don't regress.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In article <435f4d46$0$11071$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>Richard.L.Hamilton@mindwarp.smart.net (Richard L. Hamilton) writes:
>
>>I'm guessing that PROM diagnostics and such don't count, because they seem
>>to take quite a bit longer than the actual boot on some of the larger
>>systems.
>
>They are taken into account; but because they're fixed in time, they
>don't regress.
>
>Casper

This word "regress", what does it mean as used here?

(In prior msg in this thread, its use there apparantely
had to do with slow booting?)

ie:



| In article <xoavoe5defoz.fsf@sun.com>,
| James Carlson <james.d.carlson@sun.com> writes:
| > Gary Mills <mills@cc.umanitoba.ca> writes:
| >> >Got a specific bug you're interested in? I'm sure someone here will be
| >> >able to give you some more details on it.
| >>
| >> Yes, I was checking on 6322616, which is quite a recent one. The
| >> synopsis says something about `boot time regression'. I can't guess
| >> what that really means. The fix for that apparently broke a feature
| >> of smpatch in Solaris 10.
| >
| > "Boot time regression" means that the system boots up more slowly (in
| > this case, by 11.48%, according to the synopsis). (There's a standard
| > internal performance test called "boot time," hence any slow down in
| > booting time is a regression in that test.)
| >
| > We measure and care about this because folks who calculate
| > availability numbers use boot time as part of the metrics.
|
| I'm guessing that PROM diagnostics and such don't count, because they seem
| to take quite a bit longer than the actual boot on some of the larger
| systems.

David Combs wrote:
> In article <435f4d46$0$11071$e4fe514c@news.xs4all.nl>,
> Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>> Richard.L.Hamilton@mindwarp.smart.net (Richard L. Hamilton) writes:
>>
>>> I'm guessing that PROM diagnostics and such don't count, because they seem
>>> to take quite a bit longer than the actual boot on some of the larger
>>> systems.
>> They are taken into account; but because they're fixed in time, they
>> don't regress.
>>
>> Casper
>
> This word "regress", what does it mean as used here?

Most of the time, it means that a bug that was fixed, returns in a newer
release.
This would happen if the bug got fixed in a set of code, but for a next
release there was made a copy of the code before this fix, and the fix
wasn't included in the new copy, too.

> (In prior msg in this thread, its use there apparantely
> had to do with slow booting?)

The use of the word there seems to indicate that boot speed got slower,
just as slow as in some previous version. As if at some time, there was
some boot time optimization, but in a later release it seems to be gone
again.

--
Best regards,
Jeroen Besse
(to contact me: the nospam address actually exists)

dkcombs@panix.com (David Combs) writes:

>In article <435f4d46$0$11071$e4fe514c@news.xs4all.nl>,
>Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>>Richard.L.Hamilton@mindwarp.smart.net (Richard L. Hamilton) writes:
>>
>>>I'm guessing that PROM diagnostics and such don't count, because they seem
>>>to take quite a bit longer than the actual boot on some of the larger
>>>systems.
>>
>>They are taken into account; but because they're fixed in time, they
>>don't regress.
>>
>>Casper

>This word "regress", what does it mean as used here?

>(In prior msg in this thread, its use there apparantely
>had to do with slow booting?)

"Boot time regression"; the PROM is a fixed piece of
software which doesn't get slower over time.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Jeroen Besse <nospam@besse.nl> writes:

>> This word "regress", what does it mean as used here?

>Most of the time, it means that a bug that was fixed, returns in a newer
>release.

Not in this context; we measure how long it takes to boot; when the system
takes longer we say that boottime regressed; there can be many causes such
as new features added.

>This would happen if the bug got fixed in a set of code, but for a next
>release there was made a copy of the code before this fix, and the fix
>wasn't included in the new copy, too.

As a matter of principle, we first fix the new copy and test it; then
we backport the bug fix.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.