On Sun, Oct 12, 2008 at 13:56:57 -0400, Hal Vaughan wrote:

[...]

> 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.

Quoting from the first reply:

| Please look in /etc/kernel-img.conf, you'll probably find:
|
| postinst_hook = /sbin/update-grub
| postrm_hook = /sbin/update-grub

Quoting from the second reply:

| I suggest you also read the comments in /boot/grub/menu.lst. They
| explain very well that some sections of the file are likely to be
| overwritten when the file is regenerated by update-grub.
|
| 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.

These are the comments right at the beginning of /boot/grub/menu.lst:

| # menu.lst - See: grub(8), info grub, update-grub(8)
| # grub-install(8), grub-floppy(8),
| # grub-md5-crypt, /usr/share/doc/grub
| # and /usr/share/doc/grub-doc/.

and a bit further down in the same file:

|### BEGIN AUTOMAGIC KERNELS LIST
|## lines between the AUTOMAGIC KERNELS LIST markers will be modified
|## by the debian update-grub script except for the default options below
|
|## DO NOT UNCOMMENT THEM, Just edit them to your needs

Quoting from the manpage of update-grub:

| The update-grub script can be ran automagically from the
| /etc/kernel-img.conf file by adding the following lines:
|
| postinst_hook = update-grub
| postrm_hook = update-grub
| do_bootloader = no
|
| For further information related to /etc/kernel-img.conf, see the
| manpage kernel-img.conf(5).

The manpage of kernel-img.conf explains the hooks in more detail.

> 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."

He told you where to look next.

> 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."

You never provided details on why update-grub broke your system. If you
customized menu.lst yourself without reading the comments in the
original file and the documentation referenced therein then your
subsequent problem is not a serious bug.

> 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.

He had already given you all the necessary information to fix your
problem, and there was no indication that a system with a standard
menu.lst would be affected.

> 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?

He did assist you.

[...]

> 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.

He gave you clues 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?

You never followed up with evidence that a standard system would be
affected and nobody else reported this problem, therefore the bug was
closed.

[...]

--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sunday 12 October 2008, Daniel Burrows wrote:
> On Sun, Oct 12, 2008 at 01:56:57PM -0400, Hal Vaughan
<hal@thresholddigital.com> was heard to say:
> > On Sunday 12 October 2008, Daniel Burrows wrote:
> > > 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.
>
> I agree that this sort of bug report reply is annoying. I'm just
> saying that so far in this thread I've seen Christian accused of
> various forms of trying to make users feel like idiots, being someone
> who "shouldn't be handling bug reports", a developer who is "full or
> air", someone who has "no sense of social ettiquite", etc, etc, etc.
> [0] This is not true. I don't know what was in his mind when he
> wrote the bug report to which you referred (obviously), but I don't
> think he was trying to blow you off. I don't think there's any point
> in further retreads of this ancient bug, we're just going in circles.
>
> [0] his name may not have been used, but his reply to this bug
> report was being held up as an example of this type of individual.
>
> > > 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 didn't say he was right! My point is that this is a judgment
> call that sometimes gets made incorrectly. You cannot realistically
> expect us to never make mistakes.
>
> > > 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?
>
> "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 took that to mean that you thought he was insulting you.
> Apologies if I misunderstood.
>
> > 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.
>
> Like I said, I don't think there's any more point in discussing the
> history here. When I handle misdirected bugs, I usually reassign
> them to an appropriate package. I don't know why Christian didn't;
> obviously it was a mistake on his part.
>
> > 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?
>
> Personally, I try not to reply to bug reports when I'm not in the
> right state of mind. However, I've also found that there's a strong
> correlation between lacking the judgment to reply to bug reports and
> lacking the judgment to decide whether I have sufficient judgment to
> reply to bug reports. :-/
>
> > > 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.
>
> This is the general impression I got from reading your emails in
> this thread, the same way you got a general impression that Debian
> developers are hostile and uncooperative. e.g., and I bring this up
> only so you know what I'm talking about, take this comment:
>
> "I'll go even farther: In most cases they've been outright hostile
> and I've had times where they've "told me off" to justify closing the
> bug.
>
> I'm a geek to the core, but the stereotype of programmers or geeks
> that have no social skills seems to come from something and my
> experience, over the past 10 years or so of working with FOSS, tells
> me that filing bug reports is just a good way to invite personal
> abuse."
>
> The "they" refers to FOSS developers, not Debian developers, but
> Debian developers are the specific FOSS developers whose behavior
> was being discussed in this thread.
>
> Anyway, I accept your statement that I misunderstood you.
>
> > > 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.
>
> I don't make a habit of deliberately abusing users and I try to be
> helpful. But whether I want to or not, I simply *don't* *have*
> *time* to educate every user about every aspect of the Debian system.
> All I have time to do is provide the information that I think is
> relevant to their problem and hope that they'll ask for more details
> if they need them. This doesn't work if they disappear because they
> think I'm holding back information for some perverse reason.
>
>
> You said later that I said "it's not our fault and here's why". If
> that's the case, I failed in communicating my point. Of course it's
> my fault when I screw up. And of course you can find a few people
> who have had negative interactions with developers, because we all
> screw up sometimes. (and there are probably a few developers who
> really are unpleasant to deal with) I'm not disputing whose fault it
> is, I'm saying that unless [0] we create a support department and
> have people whose full-time, paid job is to be nice and helpful to
> users, developers will occasionally make these sorts of mistakes. I
> don't think it's fair to take a few examples of less-than-stellar
> emails from developers and hold them up as grounds for condemning the
> individuals involved, let alone the entire project. The
> practicalities of the situation mean that we all need to be a little
> forgiving here for things to work.
>
> That may not have been your intent, but I hope that this time I at
> least made myself clear. :-)

Okay. Point made. I should be clear I'm talking about ONE reply in the
example and that it could have been written at 3 am after a bad day.
I'm leaving out what I used to have to do all the time when teaching in
residential: Make it clear I'm talking about a particular behavior and
that it may or may not be at all typical of the person involved. I've
gotten out of the habit (after leaving teaching) of making sure I
focused on the behavior.

That also touches on the reason that I do NOT want to bring up something
like that when it involves a person who is not a member of the forum
where the discussion is happening. I was not the one who brought it up
as an example. My original point is that I don't file bug reports with
FOSS because I've had some indifferent and even hostile replies. As
I've said, there are reasons that I usually file bug reports under a
legal alias and why I used to be on mailing lists using the same aka.
It's a long story, but it's not that I'm up to anything shady.
Overall, I used to file bug reports, back when I first started working
with FOSS, sometime in the late 1990s, but gave up on it for the
reasons I mentioned. That this particular one is dated 2006 tells me
it's one I filed when I had already given up, for the most part, on
filing them.

> [0] and even if we had a paid support department, that would only
> reduce the problem, not eliminate it.
>
> > 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.
>
> The intent was mainly to defend Christian from the unwarranted
> attacks on his character that I thought (perhaps wrongly) were flying
> around this list. A secondary goal was to suggest that assumptions
> of good faith are essential to keep our social interactions
> well-lubricated. Clearly I have failed miserably at both. I hope
> that this email is a little clearer.

And I should have been clear the focus was on ONE reply, not on
Christian. Honestly, I started my business when I couldn't even afford
to buy the tech books I needed for it. I had to go to relatives, like
a kid with his eyes downcast, asking for money for reference books. I
could not have started my business without FOSS. I could have switched
over to proprietary systems several years ago if I had wanted to, but
decided I'd rather spend the money on a convertible than the thousands
it would have taken to replace all my FOSS software with stuff for
Windows.

I know what it's like to work day and night, squashing bugs and trying
to get something ready and working. I have the utmost respect for what
FOSS developers do and what they have created, including the Debian
distro, which, unlike some, is not and never has been, sold for a
profit.

So, while I stopped filing bug reports, that does not mean I don't
admire FOSS developers and what they've done. It's like a friend of
mine who is a great guy but if we start playing Monopoly, he gets nasty
and competes in just the worst way. While I think a lot of him, I've
just learned NOT to interact with him when a Monopoly board is nearby.
For the same reason, due to my experience, I don't file bug reports.
One of the reasons I get so ticked on this issue is because I know it's
a point that, if people focused on it, would help everyone in the FOSS
world.


Hal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sunday 12 October 2008, Florian Kulzer wrote:
> On Sun, Oct 12, 2008 at 13:56:57 -0400, Hal Vaughan wrote:
>
> [...]
>
> > 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.
>
> Quoting from the first reply:
> | Please look in /etc/kernel-img.conf, you'll probably find:
> |
> | postinst_hook = /sbin/update-grub
> | postrm_hook = /sbin/update-grub

Actually, I do remember looking up that info, but either didn't see all
the info I expected or found something else that was not as described.

> Quoting from the second reply:
> | I suggest you also read the comments in /boot/grub/menu.lst. They
> | explain very well that some sections of the file are likely to be
> | overwritten when the file is regenerated by update-grub.
> |
> | 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.

Yes, after I had already fixed menu.lst.

> These are the comments right at the beginning of /boot/grub/menu.lst:
> | # menu.lst - See: grub(8), info grub, update-grub(8)
> | # grub-install(8), grub-floppy(8),
> | # grub-md5-crypt, /usr/share/doc/grub
> | # and /usr/share/doc/grub-doc/.

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.

> and a bit further down in the same file:
> |### BEGIN AUTOMAGIC KERNELS LIST
> |## lines between the AUTOMAGIC KERNELS LIST markers will be modified
> |## by the debian update-grub script except for the default options
> | below
> |
> |## DO NOT UNCOMMENT THEM, Just edit them to your needs

Yes, and by then I had fixed my problem, but it STILL doesn't fix the
problem: Menu.lst is updated without telling the user. Remember THAT
was the problem! I've seen a pattern with Debian and apt: If a conf
file is going to be overwritten, I'm warned and given a choice. Now
remember that in the next point I make:

> Quoting from the manpage of update-grub:
> | The update-grub script can be ran automagically from the
> | /etc/kernel-img.conf file by adding the following lines:
> |
> | postinst_hook = update-grub
> | postrm_hook = update-grub
> | do_bootloader = no
> |
> | For further information related to /etc/kernel-img.conf, see the
> | manpage kernel-img.conf(5).

Yes, just update-grub. That's it. No script to say, "Do I overwrite
this file?" Or, "Warning: About to overwrite menu.lst." No warning,
just update-grub. This, along with any of the points on grub and
menu.lst are closing the barn door AFTER the cows have left. The issue
was NOT what is in the file, what I had or had not read. The issue was
that the file is overwritten WITHOUT warning or asking permission.

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."

If you have an antique car that takes a special oil and bring it to me
to service it and, without telling you, I just change the oil with
a "normal" one, then you start the car and the engine is hosed, what
good will it do me to explain to you how to change the oil? That's
what's going on here. In this case, you'd say, "I KNOW HOW TO CHANGE
THE DAMNED OIL! I KNOW HOW TO DO THAT! I'M MAD BECAUSE YOU DID IT
WITHOUT TELLING ME!"

That's what I'm doing, or was doing, but I wasn't shouting. The issue
was not what was in Grub, but that update-grub is run by either apt,
aptitude, or the kernel package WITHOUT warning. Do you see the
difference? 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.

> The manpage of kernel-img.conf explains the hooks in more detail.
>>
> > 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."
>
> He told you where to look next.

If you're a DD, it may be obvious. It wasn't to me. I'm sorry I'm just
not so freakin' brilliant and so aware of everything Debian that I
missed that point and could not see he was pointing, much less what he
was pointing at.

> > 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."
>
> You never provided details on why update-grub broke your system. If
> you customized menu.lst yourself without reading the comments in the
> original file and the documentation referenced therein then your
> subsequent problem is not a serious bug.

The point was that update-grub is rewriting an important config file
without prompting or warning. Does ANYONE get that?

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?

Again, this is why I don't bother. It's like talking to a brick wall
and the whole thing has wandered from the overall point. Those
responding are more interested in self-defense than listening and
saying, "There may be a point here."

> > 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.
>
> He had already given you all the necessary information to fix your
> problem, and there was no indication that a system with a standard
> menu.lst would be affected.

You say he did, you have the background so it made more sense. From
YOUR point of view, yes. From the point of view of someone who doesn't
know the system as well, no. I thought about asking for more, but my
point was an important file was being overwritten. Here's what I
wrote:

"When I did a recent "aptitude update && aptitude upgrade" I received
the prompt that I would have to reboot since kernel modules that were
the same version as my kernel were being updated. In this entire
message neither grub nor /boot/grub/menu.lst were mentioned. When I
rebooted, the system could not boot because update-grub had been run,
totally re-writing my menu.lst file.

For all other configuration files, especially files in /etc, Aptitude
prompts and asks if I want to update them or keep my current version.
There is no such prompt or warning for menu.lst. It is overwritten
without providing a choice of saving it, backing it up, or even
informing the user this is happening."

He told me about grub, he told me about the package, but at the time,
what he gave me was hard to put together with everything else (I don't
have the complete knowledge of all things Debian). Now please tell me
where, in his responses, did he deal with the issue that an important
config file is being overwritten without prompting or warning? Did he
tell me where to go to report that as a bug?

I even re-iterated this and you can see that where he quoted my reply.
Instead of addressing the point of the file being overwritten, he told
me about what was in the file.

There are a lot of reasons people might not want a config file
overwritten. They could be experimenting with different settings, they
could be working with something non-standard, or they could have
customized it for other reasons.

Yet he, and you, have entirely missed and skipped over that point and
nothing he, nor you, have said addresses it. The points you indicate
where you say he helped me do NOT show me he understood that
overwriting a vital config file is an issue, which left me feeling like
he either just didn't get it or didn't see why it was an issue.

Which is one reason I gave up.

> > 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?
>
> He did assist you.

I've responded to that previously. He dealt with everything but my main
point.

> [...]
>
> > 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.
>
> He gave you clues where to go next.

I've responded to that previously. He dealt with everything but my main
point.

> > 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?
>
> You never followed up with evidence that a standard system would be
> affected and nobody else reported this problem, therefore the bug was
> closed.

No. I didn't bother to. Here's how it went:

Hal: There's a bug here. It disables the whole system. A config file
shouldn't be overwritten without a prompt.
Christian: Not in Apt. I don't know where (he even said something like
that), but it's not here.
Hal: But there's a problem here and aptitude did it somehow (not posted
on report, perhaps I sent it directly, I don't remember).
Christian: It's in aptitude, apt, whatever. It's not a bug here. Write
to the D-U list. And here's info on Grub (not on overwriting files,
but it's about Grub!)

I had already written to the D-U list. I know he didn't know that, but
basically the source I get for other help had bombed out and at this
point I realize it's going to go on in the same pattern:

Hal: There's a problem that needs to be fixed.
Christian: It's not on what I handle, go somewhere else.
Hal: There's a problem that needs to be fixed...

(See endless loop...)
So I gave up. I had it fixed and I had other things to do, so fine,
Debian devs don't want to fix it, they don't have to. By that time I
had fixed it on my own system.

So now we have:

Hal: I don't file bug reports because I've never had one go anywhere.
Devs: You did it wrong.
Hal: Look at what I report and it led nowhere.
Devs: Oh, that's because...
Hal: Okay, let's look closer.
Devs: Oh, that's because...

(Again, see endless loop.)

And that's why I don't bother with bug reports, which is what I said a
long time ago.

You want users to file bug reports? Then listen to them and be sure you
know what they're saying and respond to that point, not to points
around that. And when they say, "There's a problem here," see if there
is instead of spending a ton of effort saying, "There is no problem."

That's what went wrong in that bug report and it's what's going on here.


Hal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hal Vaughan wrote:
> My original point is that I don't file bug reports with
> FOSS because I've had some indifferent and even hostile replies. As
> I've said, there are reasons that I usually file bug reports under a
> legal alias and why I used to be on mailing lists using the same aka.
> It's a long story, but it's not that I'm up to anything shady.
> Overall, I used to file bug reports, back when I first started working
> with FOSS, sometime in the late 1990s, but gave up on it for the
> reasons I mentioned. That this particular one is dated 2006 tells me
> it's one I filed when I had already given up, for the most part, on
> filing them.
>

Well, that pretty much summarizes the fact that you do not want to file
bugs, and the reasons why. I (and other people, judging by the thread)
think you should, but it is your right not to file any bugs if you don't
feel inclined to do that by whatever reasons you have.

That being explained, what exactly do you want to achieve with this thread?

--
Oliver's Law:
Experience is something you don't get until just after you need it.

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br
http://move.to/hpkb


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sunday 12 October 2008, Eduardo M KALINOWSKI wrote:
> Hal Vaughan wrote:
> > My original point is that I don't file bug reports with
> > FOSS because I've had some indifferent and even hostile replies.
> > As I've said, there are reasons that I usually file bug reports
> > under a legal alias and why I used to be on mailing lists using the
> > same aka. It's a long story, but it's not that I'm up to anything
> > shady. Overall, I used to file bug reports, back when I first
> > started working with FOSS, sometime in the late 1990s, but gave up
> > on it for the reasons I mentioned. That this particular one is
> > dated 2006 tells me it's one I filed when I had already given up,
> > for the most part, on filing them.
>
> Well, that pretty much summarizes the fact that you do not want to
> file bugs, and the reasons why. I (and other people, judging by the
> thread) think you should, but it is your right not to file any bugs
> if you don't feel inclined to do that by whatever reasons you have.
>
> That being explained, what exactly do you want to achieve with this
> thread?

I made the statement, as you summarized in your first paragraph. Since
then people have said, "But this is an example that disproves what you
say," or something similar. Since then I've been responding to back up
my point.

Notice that the response in the original report strayed far from the
original issue. My primary concern was never even addressed in the
responses, yet a lot of other stuff was. I gave up because I felt my
point was just not being heard and after 2 tries, it was clear to me
that we were stuck in a loop and my original point was not going to be
heard, no matter what I said or did.

So I made a point here. Some people have agreed. Not everyone, which
is to be expected, but the fact that some do shows that this has
happened often enough that there are people who have experienced it
multiple times and have given up on filing bug reports (on Debian
and/or other projects), even though devs ask for them. This is a
problem that creates problems for FOSS devs, so I pointed it out.

And, just like in the original bug report, we hit an endless loop. I've
responded over and over to try to break out of that loop, to try to
make the point: From one side, the one asking for bug reports, it's not
a problem. From the other side, it is.

Honestly, I am TRYING TO HELP! I am saying, "There's a problem," and
some people have said, "You have a valid point," but a lot of people,
especially ones on the "other side" of the issue, are so focused on
defending themselves or a fellow DD that they're talking about
everything but my original point or the original point in the bug
report.

It's the old debate trick: I can't win with the topic in question, but I
can justify what I say and win if I change the issue to one I want to
discuss. That way I can ignore the problem or issue and feel justified
that I was right all along.

Okay, I've described what I see going on.

So what am I trying to do? As I said, I'm trying to help. I'm trying
to say, "From your point of view, your justified, but there's another
point of view you don't see and from that point of view, there is a
problem. You can't see it from there, so let me show you." I'm hoping
it will make enough people think so in the future there won't be
someone like me who files bug reports, finds that in every one the
responder was either indifferent or hostile (I'm not saying Christian
was hostile, I would not use that word at all), and gives up.

I'm hoping enough devs will think about this and say, "Okay, I think
he's wrong, but on the off chance that he may be right, I'll be sure
and deal with future bug reports with attention to what the reporter is
trying to accomplish and focus on solving THAT problem, not just on
closing it out as quickly as possible."

That may or may not happen, but I do think that this thread has at least
given the issue more visibility and in that way I've done something
that could help and as long as I feel people are trying to justify
responses instead of focusing on the fact that this is an issue to
consider, I'll keep dealing with their points because I feel strongly
about this.

Hal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Oct 12, 2008 at 06:25:23PM -0400, Hal Vaughan wrote:
> On Sunday 12 October 2008, Eduardo M KALINOWSKI wrote:
> > Hal Vaughan wrote:
> > > My original point is that I don't file bug reports with
> > > FOSS because I've had some indifferent and even hostile replies.
> > > As I've said, there are reasons that I usually file bug reports
> > > under a legal alias and why I used to be on mailing lists using the
> > > same aka. It's a long story, but it's not that I'm up to anything
> > > shady. Overall, I used to file bug reports, back when I first
> > > started working with FOSS, sometime in the late 1990s, but gave up
> > > on it for the reasons I mentioned. That this particular one is
> > > dated 2006 tells me it's one I filed when I had already given up,
> > > for the most part, on filing them.
> >
> > Well, that pretty much summarizes the fact that you do not want to
> > file bugs, and the reasons why. I (and other people, judging by the
> > thread) think you should, but it is your right not to file any bugs
> > if you don't feel inclined to do that by whatever reasons you have.
> >
> > That being explained, what exactly do you want to achieve with this
> > thread?
>
> I made the statement, as you summarized in your first paragraph. Since
> then people have said, "But this is an example that disproves what you
> say," or something similar. Since then I've been responding to back up
> my point.
>
> Notice that the response in the original report strayed far from the
> original issue. My primary concern was never even addressed in the
> responses, yet a lot of other stuff was. I gave up because I felt my
> point was just not being heard and after 2 tries, it was clear to me
> that we were stuck in a loop and my original point was not going to be
> heard, no matter what I said or did.
>
> So I made a point here. Some people have agreed. Not everyone, which
> is to be expected, but the fact that some do shows that this has
> happened often enough that there are people who have experienced it
> multiple times and have given up on filing bug reports (on Debian
> and/or other projects), even though devs ask for them. This is a
> problem that creates problems for FOSS devs, so I pointed it out.
>
> And, just like in the original bug report, we hit an endless loop. I've
> responded over and over to try to break out of that loop, to try to
> make the point: From one side, the one asking for bug reports, it's not
> a problem. From the other side, it is.
>
> Honestly, I am TRYING TO HELP! I am saying, "There's a problem," and
> some people have said, "You have a valid point," but a lot of people,
> especially ones on the "other side" of the issue, are so focused on
> defending themselves or a fellow DD that they're talking about
> everything but my original point or the original point in the bug
> report.
>
> It's the old debate trick: I can't win with the topic in question, but I
> can justify what I say and win if I change the issue to one I want to
> discuss. That way I can ignore the problem or issue and feel justified
> that I was right all along.
>
> Okay, I've described what I see going on.
>
> So what am I trying to do? As I said, I'm trying to help. I'm trying
> to say, "From your point of view, your justified, but there's another
> point of view you don't see and from that point of view, there is a
> problem. You can't see it from there, so let me show you." I'm hoping
> it will make enough people think so in the future there won't be
> someone like me who files bug reports, finds that in every one the
> responder was either indifferent or hostile (I'm not saying Christian
> was hostile, I would not use that word at all), and gives up.
>
> I'm hoping enough devs will think about this and say, "Okay, I think
> he's wrong, but on the off chance that he may be right, I'll be sure
> and deal with future bug reports with attention to what the reporter is
> trying to accomplish and focus on solving THAT problem, not just on
> closing it out as quickly as possible."
>
> That may or may not happen, but I do think that this thread has at least
> given the issue more visibility and in that way I've done something
> that could help and as long as I feel people are trying to justify
> responses instead of focusing on the fact that this is an issue to
> consider, I'll keep dealing with their points because I feel strongly
> about this.

You have raised some interesting points. If you consider the BTS as a
help desk, then I think you will be sorely disappointed.

It seems that to file a bug report the submitter first has to research
the problem, try and resolve it, and if possible, to provide a patch.

I, too, am interested in other peoples views on this.

--
Chris.
======
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
-- Sir Stephen Henry Roberts


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.

[...]

> 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.

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.

[...]

> 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.

[...]

> 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.

--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 13 Oct 2008, Chris Bannister wrote:
> You have raised some interesting points. If you consider the BTS as a
> help desk, then I think you will be sorely disappointed.
>
> It seems that to file a bug report the submitter first has to research
> the problem, try and resolve it, and if possible, to provide a patch.
>
> I, too, am interested in other peoples views on this.

You are correct. The project as a whole simply doesn't have the manpower,
and often, the inclination to deal with helpdesk-level issue reports on the
BTS (they should go to the mailinglists instead).

Oh, there might exist exceptions, and I hope that most maintainers would try
to handle any sort of BTS report, as long as there aren't too many of them
showing up or a big backlog... but if the maintainer is overworked, he is
likely to ignore such reports, or to be very terse (which people, expecting
to get attention and help on the issue their raised, will ALWAYS take the
wrong way) when replying to them.

Helpdesk-level issue reports (i.e. one where there is still a huge ammount
of non-package-specific detective work to be done to narrow down the
problem) really ought to go to the user mailinglists or to the forums.
There, it can be shaped up into a more precise issue report, and finally go
to the development mailinglists and/or the BTS.

Maybe this is not the nicer way things could work, but given the constrains
in which Debian operates, the mailing lists are where we have more attention
and "human resources" to help deal with something.

I wish we could get this information out to people better, it is clear to me
that we don't do it well enough.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hal Vaughan wrote:
> But does it address the original issue? The original report is that
> menu.lst is overwritten without notice.
>

A fact that is noted in that file, by the way.

In the top, there are pointers to documentation on what interacts with
the file:
# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

OK, that does not tell anything about making changes in the file, but
further there is also:
### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

Not the best wording, but certainly gives some hints, especially if
combined with the manual pages mentioned above.

> 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?
>

You're misunderstanding a point here. The files you mention are
configuration files shipped with packages. If a package ships a new
version of the configuration file, and the file has been locally
modified by the user, you get that point during package installation.
Grub's menu.lst, on the other hand, is not a file like this, it does not
get changed because it was shipped in a package, but rather because a
post-installation script by default calls a command to update the file.
Which is, in most cases, quite useful: most users, when installing a new
kernel, will appreciate it appearing automatically in the boot menu.

So there are two different situations here, handled in different ways.
The boot.lst file (or actually, a part of it) is meant to be updated
automatically. It is possible, though, to make changes to it and not
interfere with that automatic kernel detection. You just need to make
them outside the part delimited by "BEGIN AUTOMAGIC KERNELS LIST" and
"END DEBIAN AUTOMAGIC KERNELS LIST". It is also possible to disable
calling update-grub (the program that changes the file), it is document
in one of the manual pages listed in that file.

There are certainly ways of improving that (for example, stating more
clearly in the file that some parts of it get automatically rewritten),
but you seem to have some unrealistic expectations of how that file is
handled (though it may appear similar to rsync.conf, it is handled in a
totally different way). It is unlikely that this behavior will be
changed, no matter how you complain about it. In part because what you
want to achieve can be done, you can edit the default options that
affect all automatically included kernels, you can manually include
kernel stanzas with exactly what you need, or can you even disable
automatic update of the file and do all changes yourself.

--
Blessed are they who Go Around in Circles, for they Shall be Known as Wheels.

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br
http://move.to/hpkb


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org