Subject: Re: AW: Re: Linux in a binary world... a doomsday scenario
From: Lee Revell <rlrevell@joe-job.com>
To: Dave Neuer <mr.fred.smoothie@pobox.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <161717d50512081213oab71f63ncd9ecb3d721c83fc@mail.gmail.com>
References: <6798653.142371134056986823.JavaMail.servlet@kundenserver>
	 <1134070683.3919.26.camel@mindpipe>
	 <161717d50512081213oab71f63ncd9ecb3d721c83fc@mail.gmail.com>
Content-Type: text/plain
Date: Thu, 08 Dec 2005 15:26:27 -0500
Message-Id: <1134073587.5149.4.camel@mindpipe>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1669
Lines: 42

On Thu, 2005-12-08 at 15:13 -0500, Dave Neuer wrote:
> On 12/8/05, Lee Revell <rlrevell@joe-job.com> wrote:
> > On Thu, 2005-12-08 at 16:49 +0100, dirk@steuwer.de wrote:
> > > Yes, i can see the problem.
> > > How about interconnecting it with the bugtracker?
> > > If there is a bug, and if it is related to some hardware, it is logged
> > > in the database as broken for that kernel version. If the bug is
> > > fixed, support status is ok again.
> > > All that needs to be done is entering the device once into the
> > > database, status is broken by default, and take it from there?
> > > Then it gets some goals (similar to bugs) assigned if it is a complex
> > > device. i.e. for a graphic device:
> > > * 2d graphic support
> > > * 3d graphic support
> > > * framebuffer
> > > * vesa
> >
> > If we followed your scheme 95% of supported hardware would be listed as
> > broken.
> >
> > Lee
> 
> Well, let's start proposing solutions that will work then.
> 

I like the idea of a centralized database, split up by subsystem, that's
maintained by the developers in a similar way to the ALSA soundcard
matrix.  If a user finds an inaccuracy in the soundcard matrix or
discovers a new hardware model that works they submit a bug report
against the soundcard matrix, ideally containing a patch against the
XML.

It HAS to live alongside the code in the same version control system as
the code itself so it won't drift.

Lee

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