Re: severities of blocking bugs

[Steve Greenland]

On 14-Jun-06, 11:18 (CDT), Ian Jackson <[EMAIL PROTECTED]> wrote: 
> 
> Many (most?) maintainers use the BTS severity state to manage their
> worklist.  That is, the severity is a largley a note to themselves as
> to which order to do things in or what priority to give them. 

So http://www.debian.org/Bugs/Developer#severities is no longer valid
and should be removed?

I doubt you're actually contending that, and what you're describing is
often defacto what happens (one tends to start at the top of the bug
list and work down by severity), but the severities *do* have defined
meanings, and in general should be used as such.

Conceptually, "priority" is NOT the same as "severity"; adding a
"wishlist" feature that would benefit many may be of more value and
thus higher priority than a "normal" bug that affects only a few and is
easily worked around.

There are many reasons not to mess with bug priorities on others
packages, but "it screws up my todo list" is not one of them.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Ian Jackson <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG writes ("Re: severities of blocking bugs"):
>> Ian Jackson <[EMAIL PROTECTED]> writes:
>> > As opposed to writing to demand that the maintainer spend their free
>> > time to help you fix your problem !
>> 
>> How does adjusting the severity of a bug report amount to a demand
>> that the maintainer spend their free time to solve a problem?
>
> Many (most?) maintainers use the BTS severity state to manage their
> worklist.  That is, the severity is a largley a note to themselves as
> to which order to do things in or what priority to give them.  To
> demand that the bug has increased severity is exactly like demanding
> that they edit their todo list to put your desires at the top.

You keep using the word "demand".  It's not appropriate.  Nobody is
demanding anything.  Marking it higher severity does not "demand"
anything.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Ian Jackson]

Thomas Bushnell BSG writes ("Re: severities of blocking bugs"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > As opposed to writing to demand that the maintainer spend their free
> > time to help you fix your problem !
> 
> How does adjusting the severity of a bug report amount to a demand
> that the maintainer spend their free time to solve a problem?

Many (most?) maintainers use the BTS severity state to manage their
worklist.  That is, the severity is a largley a note to themselves as
to which order to do things in or what priority to give them.  To
demand that the bug has increased severity is exactly like demanding
that they edit their todo list to put your desires at the top.

For RC vs non-RC, we have already accepted that RC bugs should
generally be at the top of a maintainer's list, and it's too much
trouble to have a separate flag for this, so that's a slight variation
on this theme.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Jari Aalto+usenet]

* Fri 2006-06-09 Ian Jackson 
> If some program lacks a feature or bugfix you want for your package,
> then _implement it_ instead of whining !
>
> Most maintainers are much more cooperative when you tag the bug as
> +patch and say something like:

Nope. If you happend to send a patch to fix the problem, there are as
many responses as there are developers. I've got messages saying
"I/We're not interested".

> As opposed to writing to demand that the maintainer spend their free
> time to help you fix your problem !

Wrong. The person responsibnle for the package is responsible for
the bugs and features (coordinating them to upstream); overall things
for the whole package.

This responsibility cannot be put on the shoulders of others.
Everybody is on their free time, the bug submitter included. The
packager has *taken* the burden, so he should also carry it. Or
otherwise he is not the right person for the maintenance - it's not a
parking garage.

> Remember also that the purpose of bug reports is to help us improve
> the package.  The purpose of bug reports in Free software is _not_ to
> solve the submitter's problem !  (Although that's sometimes a helpful
> side-effect.)

Features and improvements raise on the field. Anything that can be
improved and make quality better can be considered bug (severity may
differ).

Jari



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Steve Langasek]

On Fri, Jun 09, 2006 at 09:41:34AM -0700, Thomas Bushnell BSG wrote:
> > When you make a wishlist bug RC, you are by definition forcing someone
> > else to spend time on it, either to fix it or play BTS ping pong with
> > you, since their package doesn't need to be kept out of the next stable
> > release over a wishlist bug.

> The maintainer agrees that it's an important bug, not a wishlist bug.
> So let's not pretend that it's wishlist; it's not.

> In fact, fixing this bug has already been said by the release team is
> a release goal for etch.  So, at least in that sense, it *is* release
> critical.

No, release-critical bugs are, by definition, those that we will not
release etch without resolving.  Release goals are things that the
release team believes *should* be resolved for etch, to the point of
encouraging a relaxed NMU policy for packages related to these goals,
but they are not automatically bugs that would be allowed to delay the
release or result in a package's removal from the release.  Sorry if the
previous mail on this point was unclear.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This one time, at band camp, Thomas Bushnell BSG said:
>> Ian Jackson <[EMAIL PROTECTED]> writes:
>> 
>> > Most maintainers are much more cooperative when you tag the bug as
>> > +patch and say something like:
>> 
>> How do you think I should have applied this advice in the case of bug
>> #360851?
>
> In the same way Martin and others handled 357057?  That's because
> he wanted a compiler version transition, and he worked hard for it,
> finding out all the problems and filing bugs with patches.  Does this
> help answer your question?

No, because when I asked for the status of the work, I received *NOT A
SINGLE REPLY FROM THE MAINTAINER*.  How on earth am I supposed to help
with the transition, when a simple question "what's the state of the
transition?" is *ENTIRELY IGNORED*?

Moreover, I wasn't even asking for the work to be stepped up or
anything else.  All I wanted was *SOME* idea of the plan.  Even the
statement, "We have no plan unfortunately" would have been helpful
(and then I could say "What can I do to help out?").

> When you make a wishlist bug RC, you are by definition forcing someone
> else to spend time on it, either to fix it or play BTS ping pong with
> you, since their package doesn't need to be kept out of the next stable
> release over a wishlist bug.

The maintainer agrees that it's an important bug, not a wishlist bug.
So let's not pretend that it's wishlist; it's not.

In fact, fixing this bug has already been said by the release team is
a release goal for etch.  So, at least in that sense, it *is* release
critical.

Nor did I play ping pong; when the severity was set back to important
(not wishlist), my reaction was to ask debian-devel.  And while Steve
and Manoj gave helpful replies that understood the particular case and
the general principles--replies which will help me to do my work more
efficiently and helpfully in the future--Ian and you have given
useless replies, that show no awareness of the particular case or the
general principles.

Indeed, both you and Ian seem to be operating from the standpoint that
bug reports are "demands" and imply some kind of malfeasance on the
part of a maintainer.  It is this approach which is harmful to Debian.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> Ian Jackson <[EMAIL PROTECTED]> writes:
> 
> > Most maintainers are much more cooperative when you tag the bug as
> > +patch and say something like:
> 
> How do you think I should have applied this advice in the case of bug
> #360851?

In the same way Martin and others handled 357057?  That's because
he wanted a compiler version transition, and he worked hard for it,
finding out all the problems and filing bugs with patches.  Does this
help answer your question?

> > As opposed to writing to demand that the maintainer spend their free
> > time to help you fix your problem !
> 
> How does adjusting the severity of a bug report amount to a demand
> that the maintainer spend their free time to solve a problem?

When you make a wishlist bug RC, you are by definition forcing someone
else to spend time on it, either to fix it or play BTS ping pong with
you, since their package doesn't need to be kept out of the next stable
release over a wishlist bug.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Ian Jackson <[EMAIL PROTECTED]> writes:

> Most maintainers are much more cooperative when you tag the bug as
> +patch and say something like:

How do you think I should have applied this advice in the case of bug
#360851?

> As opposed to writing to demand that the maintainer spend their free
> time to help you fix your problem !

How does adjusting the severity of a bug report amount to a demand
that the maintainer spend their free time to solve a problem?

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Ian Jackson]

Manoj Srivastava writes ("Re: severities of blocking bugs"):
> Well, consider this.  If there is a feature someone wants from
>  a package, say kernel-pack^H^H^H^Hfoo.
>[most of scenario snipped -iwj]
> Can one now change the wishlist bug to grave as well?  I think
>  not, since the feature request for foo remains a feature request.

This is another example of a situation where people are trying to use
the machinery intended to _support_ our work as a stick to _force_
someone to do some work that they're not interested in.

If some program lacks a feature or bugfix you want for your package,
then _implement it_ instead of whining !

Most maintainers are much more cooperative when you tag the bug as
+patch and say something like:

  Here is a patch which implements this feature, which my new package
  universe-destruction-preventer depends on; I'd be very grateful if
  you could look it over and let me know what you think.

  You'll notice that I haven't taken the approach suggested by Fred.
  This is because the neutron flow can be reversed at the critical
  point, resulting in an unfortunate explosion in certain error cases.
  Instead I have made frobnicate_hairball independent of the neutron
  flow polarity.

  If you don't have the effort to make a release right now I'd be
  happy to make an appropriate NMU.

As opposed to writing to demand that the maintainer spend their free
time to help you fix your problem !

Remember also that the purpose of bug reports is to help us improve
the package.  The purpose of bug reports in Free software is _not_ to
solve the submitter's problem !  (Although that's sometimes a helpful
side-effect.)

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Manoj Srivastava]

On 7 Jun 2006, Thomas Bushnell verbalised:

>
> I have always thought that when bug X is blocking bug Y, the
> severity of bug X should be at least as big as the severity of bug
> Y.

I don't think so.

> I have recently been told by a maintainer that my logic in this
> regard is faulty.  Is it?

Well, consider this.  If there is a feature someone wants from
 a package, say kernel-pack^H^H^H^Hfoo.  Now, foo never had this
 behaviour, and changing the behaviour of foo to actually have this
 feature is not yet decided upon by upstream.  Asking for the feature
 is wishlist.

Now, if someone supposes foo should behave this new way, and
 codes a package bar that uses foo expecting the new behaviour, and
 bar now FTBS, bar has a grave bug that is blocked by foo changing
 behaviour.

Can one now change the wishlist bug to grave as well?  I think
 not, since the feature request for foo remains a feature request.

manoj
 this is not entirely a hypothetical situation
-- 
Even when he is doing evil, the fool does not realise it. The idiot is
punished by his own deeds, like one is scorched by fire. 136
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Steve Langasek]

On Wed, Jun 07, 2006 at 04:42:37PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > Nope.  A corner-case bug in a compiler may break compilation of a single
> > package.  The build failure of this package is a serious bug for this
> > package; it is not a serious bug for the compiler.

> Well, except that it seems to me that any code generation error in a
> compiler is a serious bug. ;)  But I understand the general point.
> I'm not sure I agree, but you're the release manager

TTBOMK, we have never had a compiler in Debian that had *zero* relevant code
generation errors or ICEs.  So this sets a somewhat unrealistic standard for
release-criticality.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> You probably hit a soft spot there because suddenly the bug became RC
> and blocks the package from entering testing. The destinction between
> normal and important is purely visual while serious and above have
> real effects.

This may be true, but it hardly seems reasonable.  (And it's not as if
python-defaults is waiting to get into testing anyway.)

I am *so* tired of Debian developers treating filing of bugs as some
kind of personal insult.

The python-defaults maintainer seems to ignore absolutely everything,
and suddenly perks into action--to downgrade the bug--and still can't
bother to give even two lines of response to a status query.

I confess that my disgust with this rudeness has perhaps bled over
into this question in a way that it shouldn't.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Nope.  A corner-case bug in a compiler may break compilation of a single
> package.  The build failure of this package is a serious bug for this
> package; it is not a serious bug for the compiler.

Well, except that it seems to me that any code generation error in a
compiler is a serious bug. ;)  But I understand the general point.
I'm not sure I agree, but you're the release manager

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>
>> On Wed, 07 Jun 2006, Thomas Bushnell BSG wrote:
>>> I have always thought that when bug X is blocking bug Y, the severity
>>> of bug X should be at least as big as the severity of bug Y.
>>> 
>>> I have recently been told by a maintainer that my logic in this regard
>>> is faulty.  Is it?
>>
>> Depends on how you are going to use the blocking facility, I suppose. I do
>> agree with your reasoning, though:  if Y is critical and cannot be fixed
>> without fixing X, X is also critical.  It doesn't matter at all what
>> priority X would have IF it were not a blocker for Y: at the moment it
>> became a blocker for Y, it became part of the problem causing Y.
>
> Does this mean that I was right to raise the severity of #360851 to
> serious, after bug #357057 was raised to serious?  The maintainer of
> python-defaults told me that I should not have raised it to serious.
> (Though he did not object at all when I raised it to "important" when
> #357057 was raised to important.)
>
> Thomas

You probably hit a soft spot there because suddenly the bug became RC
and blocks the package from entering testing. The destinction between
normal and important is purely visual while serious and above have
real effects.

I also think Henrique ment that you should not (have to) touch the
severity but that the BTS should automaticaly pick the maximum of X
and Y.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Steve Langasek]

On Wed, Jun 07, 2006 at 07:08:00PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Jun 2006, Thomas Bushnell BSG wrote:
> > I have always thought that when bug X is blocking bug Y, the severity
> > of bug X should be at least as big as the severity of bug Y.

> > I have recently been told by a maintainer that my logic in this regard
> > is faulty.  Is it?

> Depends on how you are going to use the blocking facility, I suppose. I do
> agree with your reasoning, though:  if Y is critical and cannot be fixed
> without fixing X, X is also critical.  It doesn't matter at all what
> priority X would have IF it were not a blocker for Y: at the moment it
> became a blocker for Y, it became part of the problem causing Y.

Nope.  A corner-case bug in a compiler may break compilation of a single
package.  The build failure of this package is a serious bug for this
package; it is not a serious bug for the compiler.

The BTS "blocks" feature may also be used to express "I'm not working on
this bug because I believe the long-term correct solution is to fix this
other bug first", or "it's much easier to fix this bug if another bug is
fixed first".  If the bug you're not working on is a build failure, that's
an RC bug on your package -- that doesn't entitle you to mark other bugs
as RC just because it would be convenient for you.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: severities of blocking bugs

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Wed, 07 Jun 2006, Thomas Bushnell BSG wrote:
>> I have always thought that when bug X is blocking bug Y, the severity
>> of bug X should be at least as big as the severity of bug Y.
>> 
>> I have recently been told by a maintainer that my logic in this regard
>> is faulty.  Is it?
>
> Depends on how you are going to use the blocking facility, I suppose. I do
> agree with your reasoning, though:  if Y is critical and cannot be fixed
> without fixing X, X is also critical.  It doesn't matter at all what
> priority X would have IF it were not a blocker for Y: at the moment it
> became a blocker for Y, it became part of the problem causing Y.

Does this mean that I was right to raise the severity of #360851 to
serious, after bug #357057 was raised to serious?  The maintainer of
python-defaults told me that I should not have raised it to serious.
(Though he did not object at all when I raised it to "important" when
#357057 was raised to important.)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: severities of blocking bugs

[Henrique de Moraes Holschuh]

On Wed, 07 Jun 2006, Thomas Bushnell BSG wrote:
> I have always thought that when bug X is blocking bug Y, the severity
> of bug X should be at least as big as the severity of bug Y.
> 
> I have recently been told by a maintainer that my logic in this regard
> is faulty.  Is it?

Depends on how you are going to use the blocking facility, I suppose. I do
agree with your reasoning, though:  if Y is critical and cannot be fixed
without fixing X, X is also critical.  It doesn't matter at all what
priority X would have IF it were not a blocker for Y: at the moment it
became a blocker for Y, it became part of the problem causing Y.

This works well if the BTS is taught to keep transitive severity status
(i.e. it raises X's severity while it blocks Y, but as soon as it is not
blocking Y anymore, X's severity should downgrade to what it once was).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

severities of blocking bugs

[Thomas Bushnell BSG]

I have always thought that when bug X is blocking bug Y, the severity
of bug X should be at least as big as the severity of bug Y.

I have recently been told by a maintainer that my logic in this regard
is faulty.  Is it?

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]