Messages in this thread |  | | | Subject | Re: AW: Re: Linux in a binary world... a doomsday scenario | | From | Lee Revell <> | | Date | Thu, 08 Dec 2005 15:26:27 -0500 |
| |
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/
|  |