Message-ID: <32209efe0706191037l1f1e6411t8d4af6dbe9b29bc6@mail.gmail.com>
Date:	Tue, 19 Jun 2007 10:37:24 -0700
From:	"Natalie Protasevich" <protasnb@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Oleg Verych" <olecom@...wer.upol.cz>,
	"Adrian Bunk" <bunk@...sta.de>, "Martin Bligh" <mbligh@...igh.org>,
	"Fortier,Vincent [Montreal]" <Vincent.Fortier1@...gc.ca>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Stefan Richter" <stefanr@...6.in-berlin.de>,
	"Bartlomiej Zolnierkiewicz" <bzolnier@...il.com>,
	"Michal Piotrowski" <michal.k.k.piotrowski@...il.com>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Diego Calleja" <diegocg@...il.com>,
	"Chuck Ebbert" <cebbert@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: This is [Re:] How to improve the quality of the kernel[?].

On 6/19/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>
> On Tue, 19 Jun 2007, Oleg Verych wrote:
> >
> > I'm proposing kind of smart tracking, summarized before. I'm not an
> > idealist, doing manual work. Making tools -- is what i've picked up from
> > one of your mails. Thus hope of having more opinions on that.
>
> Don't get me wrong, I wasn't actually responing to you personally, I was
> actually responding mostly to the tone of this thread.
>
> So I was responding to things like the example from Bartlomiej about
> missed opportunity for taking developer review into account (and btw, I
> think a little public shaming might not be a bad idea - I believe more in
> *social* rules than in *technical* rules), and I'm responding to some of
> the commentary by Adrian and others about "no regressions *ever*".
>
> These are things we can *wish* for. But the fact that we migth wish for
> them doesn't actually mean that they are really good ideas to aim for in
> practice.
>
> Let me put it another way: a few weeks ago there was this big news story
> in the New York Times about how "forgetting" is a very essential part
> about remembering, and people passed this around as if it was a big
> revelation. People think that people with good memories have a "good
> thing".
>
> And personally, I was like "Duh".
>
> Good memory is not about remembering everything. Good memory is about
> forgetting the irrelevant, so that the important stuff stands out and you
> *can* remember it. But the big deal is that yes, you have to forget stuff,
> and that means that you *will* miss details - but you'll hopefully miss
> the stuff you don't care for. The keyword being "hopefully". It works most
> of the time, but we all know we've sometimes been able to forget a detail
> that turned out to be crucial after all.
>
> So the *stupid* response to that is "we should remember everything". It
> misses the point. Yes, we sometimes forget even important details, but
> it's *so* important to forget details, that the fact that our brains
> occasionally forget things we later ended up needing is still *much*
> preferable to trying to remember everything.
>
> The same tends to be true of bug hunting, and regression tracking.
>
> There's a lot of "noise" there. We'll never get perfect, and I'll argue
> that if we don't have a system that tries to actively *remove* noise,
> we'll just be overwhelmed. But that _inevitably_ means that sometimes
> there was actually a signal in the noise that we ended up removing,
> because nobody saw it as anything but noise.
>
> So I think people should concentrate on turning "noise" into "clear
> signal", but at the same time remember that that inevitably is a "lossy"
> transformation, and just accept the fact that it will mean that we
> occasionally make "mistakes".

This is the most crucial point so far in my opinion.
Well, not only people who report bugs are smart - they are curious,
enthusiastic, and passionate about their system, and job, hobby -
whatever linux means to them. They often do own investigations, give
lots of detail, and often others jump in with "me too" and give even
more detail (and more noise) But real detail that would help in bug
assessment is not there, and needs to be requested in lengthy
exchanges (time wise, since every request takes  hours, days,
months...)
I think  would help to make some attempt to lead them on to giving out
what's important. Cold and impersonal upfront fields and drop-down
menus are taking a lot of noise and heat off the actual report.
Another observation - things like "me too" should be encouraged to
become separate reports because generally only maintainer and people
who work directly on the module can sort out if this is same problem,
and in fact real problems get lost and not accounted for when getting
in wrong buckets this way.
--Natalie
>
> This is why I've been advocating bugzilla "forget" stuff, for example. I
> tend to see bugzilla as a place where noise accumulates, rather than a
> place where noise is made into a signal.
>
> Which gets my to the real issue I have: the notion of having a process for
> _tracking_ all the information is actually totally counter-productive, if
> a big part of the process isn't also about throwing noise away.
>
> We don't want to "save" all the crud. I don't want "smart tracking" to
> keep track of everything. I want "smart forgetting", so that we are only
> left with the major signal - the stuff that matters.
>
>                 Linus
>
-
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