[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

A lot of what you're saying is right, and is great advice to the community. But in the time it took you to write that 5000+ word email you probably could have written the patch and submitted it.

"You must be the change you wish to see in the world."
  --  Mahatma Gandhi

If you'd "love to see something happen," why don't you just write the patch? It would take you 15 minutes, it would probably be accepted (or at least a variant would be), and then the problem would be fixed and you wouldn't have anything to complain about!



Hal Vaughan wrote:
On Wednesday 15 October 2008, you wrote:
Hal Vaughan wrote:
Both of your comments involve disagreements over differences of
opinion -- but I can see where you're coming from and I think the
point about rewording the warnings in menu.lst would go a long way
toward addressing the issue that led me to file the bug report.

If filing the bug report had led to that kind of discussion, I
would have felt much better about it than I did when I decided to
just give up.  I can deal with a disagreement.  What I found
frustrating was that it felt like the focus was only on justifying
why the bug was elsewhere and there was no need to pursue it.
So it sounds like one possible solution that is agreeable to most in
this discussion is to improve the documentation on menu.lst.

I'm not sure it's a permanent solution or a step toward it to my thinking. I discussed this with a friend of mine who's RPM-centric and his comment was that RPM just automatically overwrites the config files (apparently with backing them up first) and we went over several topics. One comment he made stuck with me. It was something close to, "It just doesn't work to tell people how they have to edit a config file." The more I think about it, and think about FOSS, and how the F is for "Free as in speech," the more I think that is in line with comments and reactions from people who use FOSS and why they may use a version of Linux or BSD instead of, for example, Windows.

Often I've heard (or read) people say the purpose is to enable people to have control over their computer, instead of letting their computer have control over them. Isn't that a major part of what FOSS is all about?

And now we're saying, "But you should do it this way, otherwise, you're shooting yourself in the foot." Yet I've seen many times along the way where people were doing non-standard things for dozens of reasons. Maybe it's because those were the "good ol' days" when people were still pioneering and experiment. Or maybe things have gotten so tame and standardized in FOSS that there are now ways we're all supposed to handle different things.

This friend is an admin, not a programmer, not a developer. He handles web hosting and setting up systems for other people. He reminded me of some of my points and how, along the way, those seem to have gone from important to not as important -- like the one about freedom.

Here's an example: If I edit my CUPS config and update CUPS with apt-get, I'll get a prompt. Many of us have other things on our minds other than the systems we're administrating. For many of us, the computer is the tool, the means to the end, not the end in itself. In such cases, we can do something like apt-get upgrade and forget that it'll overwrite some of our config files. Apt has taken that into account and prompts us. When we get a prompt about overwriting the CUPS config, we'll remember, or we should.

We can choose: Do we want to upgrade that file or not. We can keep our modifications that may be in there for whatever reason we want or we can give them up.

Now it's true we can do that to a point with menu.lst and that there are ways to include changes so they're not overwritten, but on the other side, is the point of Debian and FOSS to tell people, "Handle it like this or ELSE!"? Or is the point to enable people to handle their systems with some sense of freedom and to make sys admin less dependent on our attention or more demanding of our time?

Those are two important questions: Is the goal to tell people how to handle their config files or to let them make their own decisions? And is the goal to save effort or to require effort?

Some will say, "But you have a choice. Do it wrong and get hosed or not." Not a valid choice. That's the same as, "Do it our way or get burned." And therein lies the road to mediocrity: turn control of your admin decisions over to the OS creators. If I wanted a computer that did that, I'd shell out several hundred and torture myself with a commercial OS.

As it is, the choice we do NOT have is if we can experiment with that file without fighting our own computer. If we get a notice, "Upgrading or adding this package will overwrite /boot/grub/menu.lst," then we have a choice. Then, before apt automatically overwrites that file, we know it'll happen. Without such a prompt, it's a crap shoot. We can edit that file and *think* it's safe because we know we won't run update-grub (or is it grub-update -- I keep forgetting!). Yet it isn't safe because there are cases where that will be run without our knowing.

So it comes down to where is the point where it's okay to overwrite a file the user/admin has edited and wipe out any comments or changes they've put in and where is the point where we should respect the admin's changes.

Yes, many people say, "It's your problem." If that were true and the best way to do it, then it would be our responsibility to manually handle backing up all configuration files before an update. It isn't. That, in itself, shows us that the idea behind apt, as opposed to RPM, was to let people make their own choices and not assume/presume to make their decisions for them or tell them how to handle their config files and overwrite their changes with any update with the system's "good" config file.

I've found the best way to get something fixed in an open source
project is to develop a patch.  Since this is documentation, it
wouldn't be that hard.  You can find the default menu.lst around line
260 of

I've filed bug reports where I didn't know the language or enough of what was going on to write a patch but was able to specifically point out where the bug was and what it would take and still been blessed out because it was a "feature" (even when it was clear it was fubar).

I don't know how knowledgeable whoever decides to do this is, but I
can help a bit with the process if needed.  I'm not a DD, but I do
file bugs from time to time. :-)

Heck, one could even reopen the old bug, move it to grub, attach the
patch and hope for the best, but there's already another bug that's
very similar and might welcome such a patch (and a link to this
discussion): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383282

I'd love to see something happen, but, honestly, I've found it hard enough to just explain my point of view here and had a big enough hurdle getting some people to see what the issue was that it still leaves me with that feeling that I just don't feel like having to go through that whole thing with trying to fight someone in a bug report.

I will say, though, that a lot of people in this discussion have been great to exchange ideas with because they could deal with the actual topic at hand and present some good points.


Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: egerlach@feds.uwaterloo.ca

Reply to: