[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: severities of blocking bugs

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


Reply to: