Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)

[Hal Vaughan <hal@thresholddigital.com>]

On Sunday 12 October 2008, Daniel Burrows wrote:
> On Sat, Oct 11, 2008 at 12:23:01PM -0400, Hal Vaughan 
<hal@thresholddigital.com> was heard to say:
> > His (Christian's) comments were "This has nothing to do with
> > aptitude." Then he goes on to talk about update-grub and that I
> > asked for it.  No. I didn't ask for it.  I remember that situation
> > enough to remember that one reason I was frustrated was I did what
> > I thought was a normal upgrade and didn't specify other programs be
> > run.  If it was run, it was run by aptitude or a package script
> > (speaking from my perception now).  Then he goes on to tell me
> > about the postinst_hook and postrm_hook.
> >
> > At that point I'm wondering, "What the heck are those?  Why do I
> > care? Why is he telling me this?"  I don't know if he's just trying
> > to dazzle me with bs or to make me feel like an idiot because he
> > knows so much and I know nothing.
>
>   I've been working with Christian for years on the aptitude package;
> he was its translation coordinator before Jens took over.  I've never
> met him, but the impression I have from email contact is that he's
> one of the most humane individuals I've collaborated with in the free
> software world.  I've certainly never seen him try to humiliate a
> user in response to a bug report.  He also doesn't usually fiddle
> with technical bug reports, because he isn't a coder and doesn't have
> very strong technical skills; I'm not sure why he did in this case.
>
>   Regardless, I don't see his mail as being at all impolite; just
> a little terse.

I'll ask you to read in this context: 1) You know very little about how 
packages in Debian are maintained, 2) You know nothing about the 
internals of apt, 3) You do not know Christian at all, have no idea 
what he is like, and do not know what to expect, and 4) You have just 
found what has every appearance of a severe bug: Upgrading some files 
can keep a system from booting.  While your problem is resolved, you're 
trying to help the distro you prefer keep that from happening to anyone 
else.

With that in mind, notice that nothing said in those posts is at all 
helpful.  There is no effort, in any of his responses, to say, "Yes, 
there is a problem here, and while it's not my job to solve it, here's 
where to look next."  What there is, terms of a response, is, "It's not 
a bug, at least not one I have to worry about."

There was also the point that I bought up of him saying I did things I 
did not do, which left me confused.  (He said I specified to run 
update-grub, which I stated I never did unless some package did it 
without me knowing it.)  That's another point that he made no effort to 
clarify.  While it's a small thing, it's just one of many things that 
left me with the feeling his concern was more to close it out than to 
solve the overall problem.

Also note that this bug includes reporting a bug that can make a system 
100% non-functional.  Yes, it's a serious bug, yet the response is 
basically, "Not my problem, go away."  Notice he specifically mentions 
this list as a forum to address it in, which is where I brought it up 
originally.  It may not be outright rude, but when someone brings up a 
bug that is serious enough to disable a Debian based system and the 
response is, "It's not my problem," would you consider that just terse 
or something more?  Just what would you call it when someone, who can 
help, doesn't want to bother assisting someone who has found a serious 
bug?

And note I'm discussing the action, NOT the person.  I don't know the 
person.  For all I know he may spend all his free time feeding needy 
children.  I don't know and I'm not getting in to that.  That's not the 
point of discussion and neither is Christian's personality.

Also remember, this is ONE example, the one under discussion and not the 
sole one I've run in to.   I was not the one that provided this as an 
example.  I would not hold up a post, bug report, or any piece of 
writing as an example of poor behavior in a forum unless the person 
were participating in that forum where he would be able to directly 
defend himself.

> > What would be wrong with saying, "It wasn't aptitude that did this.
> >  It was a package you were updating, which could be the kernel or
> > grub itself, and the bug would pertain to one of them."?
>
>   It's hard, when replying to a bug, to figure out the level of
> detail to include.  He included enough information for someone to
> figure out what was going on if they were familiar with the Debian
> system.  

With what degree of familiarity?  I couldn't figure it out.  Now you can 
go on and call me an idiot, but I test well into the genius range, have 
depended on only my income from my business based on my own programming 
for 7 years, and have basically taught myself all the programing 
languages I now use (I'm not counting BASIC, FORTRAN, and VAX 11/780 
Assember that I learned in college, since I no longer use any of those 
languages).  While I fixed my system, I was left with no idea of what 
was actually going on and wasn't sure what to do if I wanted to make 
sure someone could prevent this kind of thing from happening again.

> I can see the point that more information would have been 
> helpful, but this is an easy mistake to make and I'd hardly call it
> an insult.  

Who said it was an insult?

Maybe it's from the jobs I had along the way, but I cannot imagine being 
part of an organization and someone coming to me for help and 
saying, "It's not my problem," without doing my best to give them SOME 
clue on where to go next.

Again, it's a serious bug.  Does it make sense, if someone says, "This 
action makes a computer unbootable" to not try to prevent it from 
happening to others also using Debian?

> (and before you ask: why don't we, as developers, always 
> include all the relevant information?  Sometimes we just forget that
> other people don't have it at their fingertips; sometimes we're in a
> hurry and biased towards writing a short response; sometimes we just
> screw up.  Sorry, we're humans)  It's an easy mistake to remedy,
> though: just politely ask for more information, as you did in this
> case.

Yes, developers are humans.  That's why I included the point someone 
considered OT: I'm a developer.  I deal with bug reports.  Not many, 
but I do, and I've also learned when someone is reporting a bug, they 
need help.  What is a bug report?  It's someone saying, "There is a 
problem."  So what's the goal of a bug report and responding to it?  
How could it be anything but to help solve the problem.  That's the 
entire purpose and goal.

>   That's separate from being outright rude.  I think we've all done
> this sometimes; the unfortunate thing is that since we usually
> interact with each user once, the one who gets a snippy reply on a
> day when we're tired or out of sorts thinks that's representative of
> how we always treat people.  In companies where people pay real money
> for the code, this is dealt with by having people who are trained and
> paid well for the psychic burden of always pretending to be in a good
> mood.  Since we don't have employees, we don't have that particular
> nicety in Debian.

Rude is a subjective term.  Being terse isn't always being rude and one 
person's rude is another person's terse.  However, as you point out, 
there are times when a developer is tired or out of sorts.  That's not 
a particularly good time to respond to "the public" (or whatever term 
you want to use.  True, you don't have employees, but was there a 
deadline hanging over his head so he *had* to respond at that time?

> > Actually, now that were discussing this, I find that helpful and
> > frustrating.  Again, I'm saying, "Something is wrong," and he's
> > saying, "It's not my job."  Then he says he thinks this is what
> > happens.  Now he's someone who knows the inner workings and I had
> > already said basically what he just surmised, but at least he sees
> > my point.  But rather than pointing me in a direction that would
> > help me know what to do, he continues with, "Then something else
> > changed it...but I have no idea what did so. The file does not
> > belong to any package.  Certainly the bug is not, definitely not,
> > an aptitude bug. You can't blame aptitude for every problem
> > happening with packages it installs."
> >
> > Do you see why I feel like this was a waste?  I took the time to
> > write up a bug and explain what I could.  I don't know apt or
> > aptitude.  All I know, as someone who uses those programs, is that
> > I ran one and it borked my system.  All I get in response is,
> > "Nope, not my package. Something else, but not mine."
>
>   I can see why you might feel it was frustrating.  Particularly if
> you automatically assume that the guy on the other end is a
> malicious, arrogant jerk rather than someone who's overworked and
> trying to deal with a bug that's clearly misdirected.

Where did anyone automatically make that assumption?  I don't see where 
anyone said there was such an assumption or why there's a need to bring 
it up.

I did make the point that this was an overall problem I've found and 
several people have said they've had the same issue.  I was not going 
to even bring up this bug as an example until someone else did.  I had 
no desire to bring it out and discuss someone else's comments when I 
had no reason to believe he was present in this forum.

> > > As for the response of Christian Perrier, I'm sure he didn't mean
> > > to be rude[2], it's just that the tone is hard to replicate in
> > > writing.
> >
> > And I'm supposed to know this --how?
>
>   By not assuming that every slightly terse reply you get is a
> declaration of war?  

Uh, didn't do that.  Go back and read my original comments.  I didn't 
start with that assumption, but it seems you want to do what you're 
accusing me of: making a negative assumption about others.

> We're all imperfect humans trying to work this 
> out together, and sometimes we file a bug report in the wrong place,
> or send a reply that in retrospect was clearly inadequate.  In real
> life we work these things out with body language and tone of voice,
> which aren't available in email, but also by asking for clarification
> and for followups, which are.  If you don't understand something,
> ask.

Yes, I've heard the "real life" argument many times.  But also for those 
of us who spend a lot of time online, we know about that and we also 
know that people don't get body language and voice tone.  I felt the 
answers were short enough that there was really no point in asking for 
clarification because, at that point, *MY* issue was solved and I 
didn't feel like trying to extract more info on the issue.  Personally, 
I figured I'd let it drop and if it ever came up because someone else 
had a similar problem, there'd be a record it was brought up and 
written off.  

At the time, the message I got was that this was someone who was more 
interested in rationalizing why it wasn't a bug than in trying to help.  
Note that nothing in the responses contradicts that impression and that 
a reading of the responses under the conditions I mentioned above make 
it pretty easy to get that impression.

> > Okay, I'm being snippy with that comment, but there's a reason for
> > it. The point has been made that I need to be nice in bug reports,
> > but there's a flip side, and that flip side was my point at the
> > start: a developer responding to a bug report has to be nice as
> > well.  That includes knowing that the bug reporter may not know the
> > program well or know all the technical details.  That means telling
> > them, in terms you are SURE they'll understand, just what is going
> > on.
>
>   This is a nice ideal.  In the end, it always comes down to a
> judgement call.  We can't send the entire Debian Reference Manual
> along with every bug reply, and it wouldn't be useful anyway.  I
> generally guess what sort of reply to write, and then adjust my
> followups according to the feedback I get.

The entire reference manual wasn't needed.  At the time, saying, "It's 
likely in the following packages," or, "Check this log for a list of 
packages.  You can find the ones that were upgraded and here's a quick 
way to check which one used update-grub."

The main point on this bug is that I had tried to say there was a 
problem, I described it, and was trying to help Debian fix it so OTHER 
PEOPLE would not have the same problem I did.  I did what people had 
told me to and what we all know should be done.  Then I ended up with a 
dead end.  Again, what's the point of a bug report?  To solve the 
problem.  There was very little given to me to help solve the problem 
and it would not have taken much to give me a better idea of where to 
go next.

>   Please remember that we are volunteers.  I spend between 5 and 20
> hours, tops, on my Debian work, depending on how much I can squeeze
> in around my other activities in my free time.  I have spent one hour
> of it this week writing this reply to you.  If I answered every user
> question in enough detail for the most naive user I can imagine to
> understand what I meant from my first reply, I would never have time
> to do anything else.

But you also have to remember that you never know much about each user.  
Today's naive user could be a developer in a few years.  Or they could 
be someone with a large bank account that might be donating soon. In 
the very least, as you point out, developers are only human, but so are 
those filing the bug reports.

We hear, as users, how important bug reports are.  File bug reports.  
Let us know about bugs.  Well, if you're going to ask for them and if 
you want them, then it's damned important to remember that when you ask 
people in, you have to treat them as guests.  When you ask for help, 
it's your responsibility to treat the helpers well.  If you're going to 
ask for bug reports, then don't ignore the ones that come in or be 
short in your replies or try to drop an issue when someone is 
concerned.  

To do so is like inviting someone in as a guest, then saying, "Why are 
you here?  I've got other more important things to do."  Would those 
guests be likely to come back again?  No.

In this case, I've reported other bugs and not received any indication 
anyone either cares or wants to work on them.  I have another one that 
started this thread, but I'm not going to bother to report it because 
my experience is if I do, then I get nowhere with it, so why waste my 
time?  How did I get that impression?  See the previous paragraph for 
an answer.

> > Remember Stargate SG-1?  Remember how Carter would get into a tech
> > explanation and O'Neill would say, "Carter?" and she'd give him a 1
> > sentence explanation anyone could understand?  It's the same here.
> > don't assume the reporter knows all the tech stuff, no matter what
> > their level.
>
>   (disclaimer: I've never seen Stargate SG-1)
>
>   Carter had writers who could come up with wonderful 1-sentence
> explanations that she could pretend to come up with on the spot.  We
> just have a -user list. :-)  That's why Christian pointed you to it:
> it's a better use of everyone's time if generalized questions like
> this are sent to the user support forum rather than being posed to
> developers of unrelated packages.

I had been to the users list.  True, he didn't know that, but, as I 
said, he could have given a few hints that would have helped me find 
what package cause the problem.

One other point: You mention you spent an hour on this reply.  What was 
the intent?  I made a point: The responses of some DDs encourage people 
to stop filing bug reports.  That's the point under discussion with one 
report as an example.  Some people said it's not at all true, but 
others have said that in their experience it is true.  That others, not 
many, but some, have had the same problem and don't bother with bug 
reports anymore, is a clear indication that there is something to what 
I'm saying.

You had an hour and you spent it saying, "It's not our fault and here's 
why."  Wouldn't that hour have been better spent saying to other 
developers, "Users aren't filing bug reports.  These are their reasons.  
Whether they're true or not, that's how some perceive the process and 
us.  Is it worth our time to fix this?  How can we change that 
perception?"

What's the point?  To say there is no problem when several of us say 
there is, or to solve any problem or perception of one?  Just like with 
my bug report, I, and others, are saying, "There's a problem."  Are you 
focusing on explaining why it's not your problem or are you trying to 
solve it?

I don't mean to attack you, but it's a point to consider.

Hal