public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Ford <david+cert@blue-labs.org>
To: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RFC: Linux Bug Tracking & Feature Tracking DB
Date: Tue, 01 Jan 2002 21:46:33 -0500	[thread overview]
Message-ID: <3C327489.5030905@blue-labs.org> (raw)
In-Reply-To: <200201010635.g016ZR6X014712@sleipnir.valparaiso.cl>

>
>
>It is not for anybody who handles large amounts of mail. I have yet to see
>a browser which does even a half-assed attempt at doing email right.
>

I handle thousands of emails a day, over a hundred emails distinctly to 
me, not a list.  I like mozilla most, but don't think I like the 
footprint or everything about it ;)

>Here (emacs + mh-e): ^ on the message, RET to confirm the folder. Managing?
>No sweat, it is just another mail folder, to be handled by the same
>commands my fingers do on their own now.
>

As I mentioned to DJ, this is fine for you, your personal database, but 
it serves no purpose for anyone else and doesn't scale well for large 
amounts of reference material.

>Plus the problem that thousands of (well meaning, but completely useless)
>reports clog up bug<foo>, rquiring hand-cleaning by somebody who _really_
>knows about the system. I.e., exactly the person whose work you want to
>spare.
>

Untidied bug reports can be flushed out of the system, they can be 
<insert action>.  By making a more intuitive system, these bug reports 
could be fleshed out better or coallated when appropriate.  By having an 
open system, anyone can do the maintenance.  You can choose different 
pools for the entries and keep the chaff "outside" until it is weeded 
through or discarded.

>Look at the FAQ for the kernel (helpfully compiled by this list). Problems
>that get identified tend to get fixed fast, so working at documenting them
>in detail makes no sense at al.
>
>If you want to know what is broken in _development_ kernels, you have to
>read this list.
>

Not everything needs to be documented or documented in detail. 
 Sometimes a simple "loopback compile err, 'loopback.c:417:foo is not 
defined' is fixed in 2.2.2." is quite sufficient.  People with 2.2.1 
will recognize the need to upgrade or generate a patch to solve their 
problem.  The FAQ doesn't address everything and not everything is 
broken.  A 'bug' database is sometimes a misnomer.

Neither the DB nor the list replace each other.  They augment each other.

David




      reply	other threads:[~2002-01-02  2:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-29  6:53 RFC: Linux Bug Tracking & Feature Tracking DB Timothy Covell
2001-12-29  7:20 ` Anuradha Ratnaweera
2001-12-29 18:55 ` Larry McVoy
2001-12-29 19:08   ` Edgar Toernig
2001-12-29 22:13     ` Daniel Phillips
2001-12-29 22:52       ` Edgar Toernig
2001-12-29 23:02         ` Larry McVoy
2001-12-29 23:29           ` Edgar Toernig
2001-12-29 23:45             ` Larry McVoy
2001-12-29 19:16   ` Timothy Covell
2001-12-29 23:32 ` Stewart Smith
2001-12-29 23:45   ` Dave Jones
2001-12-30  5:24     ` Stewart Smith
2001-12-30 12:12       ` Dave Jones
2001-12-31  0:42         ` Richard Gooch
2001-12-31  0:44           ` H. Peter Anvin
2001-12-31  0:47             ` Richard Gooch
2001-12-31  0:52               ` H. Peter Anvin
2001-12-31  1:16                 ` Richard Gooch
2001-12-31  4:58                   ` H. Peter Anvin
2001-12-31  5:07                     ` Richard Gooch
2001-12-31  0:47             ` Arnaldo Carvalho de Melo
2001-12-31  0:49             ` Dave Jones
2001-12-31 21:50             ` Rob Landley
2001-12-31 19:40         ` David Ford
2001-12-31 19:27     ` David Ford
2001-12-31 20:00       ` Dave Jones
2002-01-02  2:27         ` David Ford
2002-01-01  6:35       ` Horst von Brand
2002-01-02  2:46         ` David Ford [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C327489.5030905@blue-labs.org \
    --to=david+cert@blue-labs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vonbrand@sleipnir.valparaiso.cl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox