On Wednesday, April 03, 2013 09:40:50, Ian Jackson wrote:
> 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.
I agree with this. I couldn't understand the your original statement, because
it sounded completely dismissive of the submitter's problem -- whereas what
you really meant was that the submitter's problem wasn't the /main focus/ for
a particular package. ;-) Okay... just miscommunication.
> 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.
This may be fact, but I will not accept this anyway, because closing bugs with
zero explanation of any kind is of /negative/ help. Even a statement such as
"please look into this yourself, I'm overloaded" would be something. But now
we've excused everything, /and/ we're saying that it's abusive for the
submitter to reopen the bug. That seems twisted.
I like Russ's suggestion of emailing -devel for an explanation, so that some
maintainer that isn't overloaded might be able to explain what's going on.
That's an answer that seems to fit both of our perspectives.
> > 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.
Wow... that's interesting. Ouch/good/weird.
> 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.
With the perspective I'm now gaining on the packaging side, I'm starting to
understand what you mean by this.
> > 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.
At the moment I'm a bit surprised and somewhat dismayed at the perspective
above, because this clashes with what I thought I knew about how to deal with
bugs in the BTS. I don't think I've seen this perspective in written
documentation anywhere.
I'm glad to consider this new perpsective though.
Personally, I always considered bugs to be "a conversation" between the
submitter(s) and the maintainer(s) -- hopefully friendly, usually
professional. From that perspective, a bug report is a free-form working out
of what to do concerning a problem. The submitter generally takes the point
of view of the issue seen on the "real-world use" side, the maintainer
generally takes the point of view of the more global view of the package in
general, and each works to meet in the middle.
But what I'm hearing here is a point of view akin to "It goes from God, to
Debian, to the Maintainer -- get it? If the maintainer won't talk, too bad."
It doesn't sound reasonable.
> > > 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
> ...
In a situation where the maintainer tells me he's overloaded and needs help
with another bug, I'm likely to try and help. (This almost never happens.)
In the situation where the maintainer has insulted me by closing the bug
without any reply of any kind at all, I'm not. If the maintainer is too
overloaded even for a one-liner reply, the mainatainer is obviously going to
be too overloaded to review anything I try to help with, too. Unfortunately
AFAICT a total lack of communication doesn't seem to be helped with more
communication attempts. :-/
My perspective may continue to change, though. I'll keep the above in mind.
Thanks much.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.