Re: [all candidates] Removing or limiting DD rights?
Chris Knadle writes ("Re: [all candidates] Removing or limiting DD rights?"):
> On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
> > The purpose of a bug report is not to help solve the submitter's
> > problem.
>
> ... No, I don't agree with this. I understand that this reteoric
> helps "explain away" the problem, but it "throws out the baby with
> the bath water". If this is in fact the case, why would I bother
> writing a bug report in the first place?
Well, speaking personally, I write bug reports because:
1. I regard bug reports as contributions to helping improve the
software;
2. Debian being improved, even if only eventually and even if only
perhaps, is directly in my interests as a user;
3. It is often the case that the work necessary to identify and fix
the bug provides, as a side effect, a faster fix for my own
problem - and if I'm lucky someone other than me may have the
skills and ability to to this much more easily and quickly than
I could do so myself (and as a consequence perhaps I get the fix
much sooner or with much less effort than if I work by myself;
4. When I'm one of the people responsible for the package, reporting
the bug keeps it on my todo list.
My point 3 above shows that the _submitter's_ motivation for reporting
a bug may be different from the project's purpose in providing a bug
reporting facility. But as the project we must not subsume our
primary goal - improving the software for all users - in favour of
serving the specific user's goal.
It is not a service to our users as a whole to get distracted from
improving the software into the task of helping a particular user.
Improving the software will help the thousands or millions of people
who use it - and although we can't see those thousands or millions
directly, they are much more important than the one user in front of
us.
Of course we do need bug reports to be able to tell what's wrong so
that we know what to fix. But many packages have so many bug reports
that there is already not enough time to deal with them all
thoroughly. In that case it is better to cherry-pick the ones which
seem to be likely to lead to bugfixes, and close the rest.
> Seriously, what I'm trying to do is lower the number of cases which
> cause frustration and which don't get any traction. Between the "
> *close* " problem, the maintainers that are MIA without the package
> being orphaned, maintainers dropping working on a particular
> package, and maintainers leaving certain bugs open forever with no
> response, a fair number of the bugs I've dealt with go nowhere.
> When I go to open a bug, I know there's a fair change that I'm just
> wasting my time. :-/
I take a rather longer view. My experience is that many bugs I report
stay open for many years, but most of them do eventually get fixed.
But then there are also many bugs I don't bother reporting, precisely
because when I imagine what the maintainer will feel about my report I
decide I would be hindering rather than helping.
> That's debatable. It's certainly dismissive, and dismissiveness is
> one method that's used for abuse. All that has to happen to make
> this *close* thing clearly abuse is for ping-ponging of open-close
> of the bug,
If the maintainer closes a bug, and the submitter reopens it, and the
maintainer closes it, then IMO the submitter has probably committed
abuse, whereas the maintainer has committed no abuse and is merely
asserting their authority.
If the submitter keeps reopening the bug, the maintainer is entitled
to close it again as many times as they like until either the
submitter gets bored and goes away. The maintainer is also entitled
to complain to owner@bugs.
> or statements like "Are we having fun yet? *close* "
> from the maintainer. The first close without explanation is almost
> invariably at the start of all that.
I think that "Are we having fun yet? *close*" is a suboptimal response
to abusive reopening by a submitter. But it falls short of being
itself abusive.
> > Of course if a maintainer inappropriately adopts such an aggressive
> > approach to bug triage when it isn't necessary, you can appeal to the
> > Technical Committee. I doubt the TC would want to set out a decision
> > overruling a maintainer's workflow (and in any case it's hard to see
> > how such an overruling resolution could be made practical).
> >
> > So if you want to do this, you will need to assemble a team to take
> > over the package and ask the TC to depose the maintainer(s). But
> > wouldn't it be better to volunteer to join the team for the package,
> > and help out the maintainer cooperatively ?
>
> Starting off with a maintainer that closes my bug report with no
> explanation at all?
If you and your allies have enough time and knowledge to help with the
package, then yes, you can certainly help with this.
You could write to the maintainers:
I notice you closed my bug without comment, so I went to take a look
at the rest of the bugs for gnomovision. You do indeed seem to
have a bit of a bug overflow crisis.
I asked Alice for help; we took a look at the list and you'll see we
have followed up with triage or status changes to a few of the open
bugs which had the most obvious next steps.
Please let us know whether this was useful. Would you like us to
carry on with some of the less obvious bugs ? For example:
#739130 probably needs to be reassigned to splurge-piper
#739312 looks like a mips toolchain bug, will RFH to the mips porters
...
Ian.
Reply to: