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

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

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 

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 

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
> /usr/sbin/upgate-grub.

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.


Reply to: