Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Saturday 11 October 2008, Andrei Popescu wrote:
> On Sat,11.Oct.08, 10:20:57, Hal Vaughan wrote:
>
> [...]
>
> > I still maintain that the issue had more to do with the issue than
> > the response said, however in that case, but I felt the responder
> > was more interested in writing it off than in dealing with the
> > issue or helping me figure out where the bug should have been
> > categorized under.
>
> Sorry Hal, I have to disagree here. Aptitude is just a package
> manager frontend, it doesn't have any responsibility whatsoever about
> what maintainer scripts do on your machine (in this case it's the
> scripts of linux-image-*). You would have triggered the same
> behaviour by 1) using apt-get instead of aptitude[1] 2)
> dpkg-reconfigure linux-image-*.
Just yesterday I installed Etch on a new Soekris box that I had to use
LILO on instead of Grub. While adding the packages I needed on it, it
kept holding back a kernel image until I installed it specifically and
only that one package. When it installed the kernel, I got updates on
what was going on, including when LILO was being run and what
configuration files were replaced.
The following may sound snippy, but I'm just trying to make the points I
feel are important. I'm not trying to jump on you, but I'm also trying
to get this out quickly because I have to be somewhere soon. If it
sounds snotty, it's because I need to send it out now, since I may not
have time to finish it for a day or two, depending on a family member's
health situation.
Now, granted, I've been making my living as a programmer for about 7
years now, but on the flip side, like many of us, I don't have time to
study the code of every package I use.
In that case, I ran aptitude and didn't get any, "Overwriting menu.lst"
message, but many times I run aptitude and get a choice of whether or
not to overwrite a config file or keep my current one.
Now, as an end user, how am I supposed to know if these messages are
coming from Aptitude or the script in the package? Am I supposed to
comb through the code and find out that it's not aptitude but a script
it runs? I'm sorry, but at the time I was spending most of my life
trying to get my own business in good shape as well as working with my
Mother to care for my Father, who was dying of leukemia. While that
isn't directly connected to the bug report, the point is that I'm
TRYING to help by saying, "There's a problem here." I don't have time
to come through the inner workings of apt or aptitude and neither do
many who file bug reports.
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.
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."?
When I finished reading his comment I still had no idea what was going
on. I had no useful information. I said, by filing a bug
report, "There is a problem here." What do I get? Basically, "Well,
it's not my problem. Everything here did what it should." I get
comments on hooks, but nothing clear enough to tell me what to do to
report this actual problem. Just reasons why I'm in the wrong place.
He had one useful suggestion, which was to read the comments in
menu.lst, however, look at that file. Look how much info there is. I
was changing an option in the automagic kernel list and had read
comments around that area. I had no idea or reason, originally, to
think that if I made a change in that section, I also needed to read
all the other sections as well. Like many of us, I'm self taught in
Linux and have read, by now, a few thousand man pages. If I had read
each one all the way through whenever I needed something new, I'd still
be reading them and my business would be nothing but paperwork
downtown. We can't know all the issues with every program or package
we use. Yes, in this case, that was helpful.
Then on the next comment from him, the only comment that might be
helpful at all is, "I guess that the update you made installed a new
kernel image...which trigger an update of the grub menu file when the
postinst script of the kernel image package is run."
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."
So what did I gain? Did he even give me a list of suggested packages
that might have caused the problem? All I knew is that a package is a
black box. Now I know there are scripts with them that run different
programs, but I have no idea how to figure out which one would have
created the problem. As I said, in all other cases, when a file is
overwritten, I've been given a choice or warning and got nothing here.
As a reporter, that's what I know. What he said in response was either
over my head or totally useless. Re-read the report from the point of
view of someone who doesn't know the inner workings, who is not a DD,
and then ask yourself, "If I didn't know a thing about apt, and filed
this report to try to save others from this problem, would I find the
developer's responses helpful?"
I think you'll come to the answer I did: they're not helpful, they don't
give me any idea where to look next and in some cases, like when he's
talking about hooks, he goes straight into the heavy tech stuff for
that particular program that just leaves me confused. I respond,
trying to get more info, and the basic response I get in return
is, "It's no my job."
So what was the point in filing a bug report? And with responses like
that, why try filing another?
> 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?
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.
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.
It also helps, if you're saying, "The problem is elsewhere," to at least
give the person an idea where to go.
It does NOT help, at all, to do nothing more than say, "No, the problem
isn't here." Then I don't know if he's being conscientious or if he's
just trying to close out the bug report. I got the strong feeling he
just wanted the bug closed and wanted me to go away. Again, re-read
the link from the point of view of someone who doesn't know a thing
about the inner workings of dpkg or apt and see if you don't get the
same feeling. It's like he's basically just giving me a list of
reasons why it's not his problem and makes no effort to tell me who's
problem it is.
> [1] actually dpkg is the one installing packages and running the
> maintainer scripts. AFAICT apt[itude] just feed it a list of packages
> to install/remove/whatever.
And it would have helped if I were directed there or at least
told, "It's likely grub or the kernel package or the kernel source
package..."
Again, I don't mean to be short, but I have time limits and,
unfortunately, that also means it's easier for me to just write a
longer reply with all the points I have than to edit it and shorten it.
If things go well and I have more time this weekend, I'll be glad to
discuss it more.
I do appreciate that someone cares enough about my point that it's easy
to discourage people from filing bug reports to discuss it. Thanks for
the interest in the subject.
Hal
Reply to: