Date:	Sun, 6 Jan 2008 22:08:13 +0100
From:	Willy Tarreau <w@....eu>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Matthew Wilcox <matthew@....cx>, Ingo Molnar <mingo@...e.hu>,
	Peter Osterlund <petero2@...ia.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@....linux.org.uk>
Subject: Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"

On Sun, Jan 06, 2008 at 09:58:02PM +0200, Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
> > I, as an end user of ntpd, have been harrassed to use it to get an
> > ntp bug reported "because by mail it would get lost". What complicated
> 
> Noone knows how many thousand bug reports have never reached lkml 
> since majordomo silently dropped them.

Since none of my mails has been dropped yet, I think that the false
positives are rather rare. Yes, sometimes someone complains about a
mail getting repeatedly killed. But that's not *that* much frequent
IMO and people are already used to re-post when mailing their friends,
coworkers or customers. It's no different here. Still, I agree that
it is a problem.

> This is the price for having lkml relatively spam-free.

yes and I think it works fairly well.

> > an interface it is when you don't know it ! I remember I wanted to
> > attach a patch and it didn't even get through the first time. I did
> > it wrong. Blame me if you want, but an interface which need training
> > for proper use is certainly not for casual end users.
> 
> What exactly is the problem with attaching files?
> What is "it didn't even get through the first time" exactly?

Well, it's quite old in my memories, it may be 2 years ago. IIRC, when
I wanted to attach files, I got brought to another page for this, and
once done there was some confusing indication about how to complete the
filing or get back to terminate the report. Sorry for not being much
precise on this one, it's too far ago.

> > Also, it's very annoying to have to create an account somewhere, leaving
> > there one of the passwords you use on many other sites, just to help a
> > random developer fix a bug in his code. You quickly wonder if someone
> > else will report it and have more patience.
> 
> If you already lack patience at this point,

Well, it took me 2 minutes to send my patch to the maintainer by then,
he very politely told me that the only way was through bugzilla, and
then it took me half an hour if not more to create a bugzilla account,
find how to use it, attach the files and put a description in a text-area.

Also, I remember that the ongoing mail exchanges through bugzilla
systematically removed the mail history, which made it very hard to
follow a discussion, because all mails I received were almost single-lined
looking like "how did that happen ?" or "in what circumstances ?" without
any history... Maybe this is configurable though.

> would you be willing to 
> bisect which requires more than a dozen kernel recompiles and reboots?

Certainly not! But I would like kernel people to become less egocentric
and understand that what they routinely do all the day appears very
complicated and time-consuming to many users, and that by imposing them
complex and/or costly methods to report bugs, they filter a lot of
reports out. Sure, there are still a bunch of them doing everything
up to and including the git bisects. But what percentage ?

People who encounter problems at work will not do that to start with,
because they cannot delay all their work to spend half a day building
kernels when their boss or customers are waiting for their work. Others
will report the problems they encounter at a customer's and will not
even be able to git-bisect because the customer's mail server is not
like a notebook they have everywhere with them and can reboot at will.
Some of them are more free of their time and will probably enjoy the
experience, but they are a minority IMHO.

If we had stats on the periods git bisects are run on, I suspect that
night and week-ends are the most frequent moments, simply because it's
when people have time.

IMHO, git bisect is excellent for kernel people. Not for random users.
They first have to install git, find free space, *clone the kernel tree* 
and start discovering the beast.

> > Another recent example: a coworker recently told me he installed the
> > latest beta from ubuntu, and that he had some problems with his WIFI
> > randomly hanging. I asked him if he filed a bug, he replied me "no,
> > it's too much boring, I'm not the only one with this hardware, others
> > have certainly already done it". When the release went out, he insisted
> > telling me he was right not filing the bug because indeed it was fixed !
> 
> He wouldn't have sent a bug report no matter how to report it.

I don't agree. It's a matter of effort vs expected advantage. Just
sending a 5-lines mail from work presents a lower entry barrier than
having to create an account and discover a new tool.

In fact, from the user's perspective, filing a kernel bug report is seen
as something annoying and useless, simply because the kernel is so much
used that someone else will file the same bug anyway. They act just like
microsoft users. Do you know anyone in your relatives who has *ever*
filed a bug to microsoft ? Probably zero. They passively wait for the
next patch, and just whine if their bug does not get magically fixed.

We must understand that our users who file bug reports are not doing this
*for them* anymore, they are offering us *presents for free*, because
someone tells them "report it before the release so that it gets fixed".
We must do everything to incitate them to do so. If the present becomes
even slightly annoying, we never get it. Have you noticed the number of
"me too" on the list ? Users find any sort of excuse for not having filed
a report in the first time, but are still willing to confirm another
one's bug. That's normal, they're just humans after all.

The ones making the most efforts are those with driver problems on rare
hardware, or those who encounter problems which look very specific to
their setups, because they know that nobody else will work on a fix if
they don't report the problem.

> > We must accept that end users :
> >   1) do not like creating accounts (remember or divulgate passwords,
> >      and risk of getting spam)
> 
> Send _one_ email to lkml and you'll get forever spam to this address.
> With one email addresses of mine exactly that happened.

That's true too. But given the number of people who randomly forward
stupidities by mails to lists of "friends" from their work address, I
think that getting their address spammed is not a problem for many of
them.

Oh and BTW, mail addresses entered in bugzilla are publicly readable
anyway. I've just randomly picked bug #1234 and the reporter and
participants may trivially be spammed.

> >   2) do not know how to classify their problem, and are not even
> >      sure it's a real bug. On the first page, when uncertain they
> >      would probably click "Other". Adding doubt in the reporter's
> >      mind is counter-productive as it will refrain him from being
> >      precise about what he did to get the problem.
> 
> If the bug ends at Other/Other that's not a problem - this usually gets 
> fixed within a few hours.

OK, but we should indicate it clearly at the very beginning :

 "If you don't know which category your report belongs to, simply
  select Other, and it will be qualified by a more skilled person"

> >   3) are not familiar with our vocabulary :
> >      - "Tree" : mainline? mm? mjb? ac? what's that ?
> >      - "Component" : Configuration? LSM? Modules? Other?
> 
> Then let's improve that.
> 
> >   => finally, I'm not sure I had to click "Other" in the first place,
> >      I want to choose something else, I click "Back" and I get back
> >      to the login page! Bye bye.
> 
> Works fine here.
> 
> Did you disable cookies?

Not at all (I don't even think the web works well anymore without cookies
these days). I retried. In fact I was still authenticated it seems, I
think that it's just that the login page is poorly placed in the sequence
of pages. By clicking on "back", I intuitively expected to get back to
the selection of another category.

> > Also :
> >   "No binary modules - NVIDIA users this means YOU!"
> >    => about half the reporters will wonder if they should stop here
> >       or not. Most of those with an NVidia chipset and/or graphics
> >       card will wonder, while the bug may still interest us.
> 
> Then sugggest a better text.

 "Before reporting a bug, please ensure that you can reproduce the
  problem without any binary module loaded (such as Nvidia's drivers,
  ndiswrapper, etc...). Ensuring that a problem happens without any
  third party drivers (which are not provided with the kernel) increases
  your report's accuracy and avoids wasting developer's time. If you
  are not sure, please check for [blacklist names here] by running
  'lsmod|more' in a shell window. If you do not know how to run without
  those drivers, please still file the report, it may still be considered
  valuable, but you may be recontacted and guided to unload them."

> > At least, on the mailing list, there's no real rules, the mail will
> > be posted anyway. And if the user gets flamed, at least we have the
> > report.
> >...
> 
> If majordomo didn't drop it.

You seem to have experienced a lot of trouble with LKML!

> And if it didn't get ignored and forgotten.

... by maintainers who deliberately refuse to read LKML ? :-)

Seriously, LKML is bad for *long term* tracking, as most people will
rotate their mailboxes once a month or week and old mails become dead
archives with no reminder. Something like bugzilla makes it possible
never to forget them. But the expensive work is still to get the bug
description there without discouraging newcomers.

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists