linux-kernel - Re: [patch] scsi: revert "[SCSI] Get rid of scsi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080106191044.GA1105@1wt.eu>
Date:	Sun, 6 Jan 2008 20:10:44 +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 08:56:25PM +0200, Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 07:34:02PM +0100, Willy Tarreau wrote:
> >...
> > As to using bugzilla for bug tracking... Well, I agree that bug
> > tracking is important when you work on multiple problems at once.
> > But bugzilla should be the developer's tool, not the end user's.
> > That means that it should only be our job to create entries there
> > if end users find it too difficult, and that we should just invite
> > them to *try* to report there to save us some time.
> 
> Where does this opinion end users would find Bugzilla too difficult come 
> from? Many other projects use Bugzilla without big problems.
> 
> Is this just plain FUD or based on real reports from end users?
> In the latter case, please give pointers to them so that whatever 
> problems exist can be fixed.

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

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.

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 !

We must accept that end users :
  1) do not like creating accounts (remember or divulgate passwords,
     and risk of getting spam)

  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.

  3) are not familiar with our vocabulary :
     - "Tree" : mainline? mm? mjb? ac? what's that ?
     - "Component" : Configuration? LSM? Modules? Other?

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

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.

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.

> And different to LKML, you don't run into problems like majordomo 
> silently dropping your email because it contains HTML or a vCard.

That's true. But do we have statistics on the ratio of client IP
addresses which go as far as the login page and which have finally
not filed their bug (either stopped at the login page or given up
after logging in) ? It should be very interesting...

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/