Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Monday 13 October 2008, Florian Kulzer wrote:
> On Sun, Oct 12, 2008 at 17:44:08 -0400, Hal Vaughan wrote:
> > On Sunday 12 October 2008, Florian Kulzer wrote:
> > > On Sun, Oct 12, 2008 at 13:56:57 -0400, Hal Vaughan wrote:
>
> [...]
>
> > > > With that in mind, notice that nothing said in those posts is
> > > > at all helpful.
>
> [ snip: quotes from the bug report and from manpages ]
>
> > And when I went through my initial setup with my issue (which
> > involved a funky Adaptec card) I followed a HOW-TO written up so I
> > could see what was going on. Remember Daniel's point that devs are
> > only human? Guess what? So are end users. If I read every man
> > page in detail on every program or conf file I use, I'd still be
> > reading. I'd have never gotten anywhere. You know that as well as
> > I. Have you read the full details in each man page you use? Have
> > you ever had to just follow a HOWTO or something similar and make
> > sure it works and move on? If so, you know what I mean. If not --
> > well, I seriously doubt anyone here thinks we all can read EACH man
> > page or each conf file in entirety.
>
> I only wanted to point out that there is a direct logical line from
> the replies to your bug report to the relevant documentation.
> Therefore I think that your complaints about not receiving any help
> at all with your problem are unjustified.
But does it address the original issue? The original report is that
menu.lst is overwritten without notice.
How many times have you run apt-get update && apt-get upgrade and gotten
notices about a config file in /etc being overwritten? You get notice.
So why not for a file that's just as important, and maybe even more
important?
While I made my point on this, perhaps I shouldn't have since the whole
issue of documentation on menu.lst still skips the primary issue of the
report: An important config file is overwritten without notice or
consent.
Am I the only one that finds a problem with config files being wiped
out?
> [...]
>
> > Which, when I filed the bug, made me wonder, "Did he READ what I
> > said? He's telling me what Grub does, but he's NOT addressing the
> > issue of the file being overwritten."
>
> Your reaction to his initial reply does not seem to be on the BTS;
> there are some snippets that he quotes in this next mail, but I have
> no way to know how much is missing and what was said in these missing
> parts.
I don't remember why it's not there. Perhaps I sent it directly to
him. I don't remember.
> AFAICT from what is on the BTS, you had an acute problem (to find out
> what triggers update-grub so that you can avoid that in the future),
> and a wishlist-level suggestion (that update-grub and/or the kernel
> postinst script and/or the documentation should be more verbose about
> what happens by default when a stock kernel is upgraded). He helped
> you with your problem and was not interested in dealing any further
> with the wishlist item. That seems fair enough to me, seeing that
> there was no indication that a system with the default menu.lst (or
> with a menu.lst customized according to the inline comments) would be
> experiencing any problems. You cannot expect a developer to bend over
> backwards for a wishlist issue, especially one that has been filed
> against the wrong package.
So you don't see overwriting an important config file -- one that can
bring down the entire system, as a problem?
I just don't see why he didn't see that as an issue of importance and I
am a bit confused that everyone keeps talking about the comments in
menu.lst and other issues and all the other points in the bug report,
but that still leaves the point of the initial bug report. Apt or dpkg
or something always warns us when it's about to overwrite a config
file. Usually we get a 4 choice prompt, the same prompt every time.
Something like Y/N/K/R for Yes/No/Keep/Replace or something like that.
So if rsync.conf or mdadm.conf is worth prompting the user before
overwriting, why not one of the few config files that the system needs
to even boot up?
> [...]
>
> > That he dwelt on the info in the remarks in the file and
> > avoided the issue that the file was overwritten without warning
> > made me wonder if he had even gotten my point.
>
> He pointed you to the kernel development list as a possible venue for
> bringing up suggestions about the user interface of the installation
> scripts, so it seems to me that he got your point.
I didn't go to lklm or anything like that because it's not an issue for
them, which I think is quite clear. It's an upgrade issue.
> [...]
>
> > Or are you so intent on saying, "We, the DDs, are blameless and
> > everything is perfect, and YOU are wrong" that you don't see that
> > point?
>
> I am not a Debian developer and I have never pretended to be one. I
> am a Debian user and I speak for no one but myself. I am merely
> expressing my personal opinion about the only case that is accessible
> to me for looking into your claims about the reception of your bug
> reports by developers.
I can understand that.
Hal
Reply to: