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
side-effect.)
Ian.
Reply to: