LCDproc development and user support list

Text archives Help


[Lcdproc] orphan drivers


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] orphan drivers
  • Date: Wed Jul 30 10:49:01 2003

First a partial reply with an other subject. The rest later.

On 29 Jul 2003 at 21:40, Rene Wagner wrote:

> On Tue, 2003-07-29 at 20:11, Joris Robijn wrote:
> > > In order to avoid a big period of time where 0.5 will be broken for
> > > most
> > > driver, it would be nice to freeze and make downloadable a nightly
> > > build
> > > so that if CVS or new nighlty build are broken, it is still possible to
> > > have one of the latest working 0.5 (without that nice feature).
> >
> > It should be committed as one thing. Then there is no problem (if it's
> > done properly of course)
>
> The problematic thing about driver or driver API changes is that
> you simply don't have all the hardware that would allow you to
> test what you've done...
> So, at the end of the day, you will always need those who have
> the hardware to at least confirm that your changes are correct
> and don't break anything.

Well drivers for which we don't have a maintainer or tester are a big
problem anyway. We regularly get requests for them, and sometime we just
say "write it yourself".

If there is an API change those drivers are a problem too. A change like
what I proposed will "probably work" by using Coding In the Dark. But I
agree with you we can't really make big API changes without those
maintainers or testers. That means that drivers for which there is no
maintainer or tester are getting us stuck anyway.

I don't want to get stuck only because we want to support all devices
that some person has ever written a driver for. We might have to leave
some orphan drivers behind. Drivers fortunately have no feelings, as far
as I know, so we don't need to feel guilty. Maybe we should keep a list
of drivers that have been tested at a certain date.

Joris
--
Joris Robijn
<joris AT robijn.net>
Mobile: 06 288 41 964

// To understand recursion, we must first understand
recursion





Archive powered by MHonArc 2.6.18.

Top of page