LCDproc development and user support list

Text archives Help

[Lcdproc] orphan drivers

Chronological Thread 
  • From: Luis.F.Correia AT (Luis.F.Correia)
  • Subject: [Lcdproc] orphan drivers
  • Date: Wed Jul 30 11:07:01 2003

Although I'm not a coder, just an overall reader of this mailing list,
here's how I see LCDproc right now.

And please, no flames, ok? This is just a comment.

Lcdproc (any version) is a valuable peace of software , although the
specifications are very hard to find.

Starting with the API.

There should be a place in the webserver (omnipotent or sourceforge)
where the current valid API's (0.4.x and 0.5.x) are perfectly described.

The most things programmers ask when writing new clients is this API.
Normally the default response is: 'read the whatever.c source code
for a practical example'. This scares off most programmers, me included.

The stable API (0.4.x) should be published.
Of course, practical example code must be provided.

The unstable/development API (0.5.x) should also be published.
Side-notes must be taken, to warn the programmer of potential API changes.

Then, in this mailing list, there is a lot of discussion over very tiny
details, that slows down development to almost a complete halt.
All we need to look for is the date for the stable release...

(from the download page) LCDproc v0.4.3 Released May 30, 2002

I know i'm now helping. I'm even confusing some.

PLEASE! agree to something and release.
Then support new stuff in new releases.

Keep changing the API as many times you want, BUT for each API a release
must exist.

That is all.

Thanks a lot to ALL coders who actively support LCDPROC.

p.s. the lcdproc package for Bering uClibc is packaged and maintained by me.

> -----Original Message-----
> From: Joris Robijn
> [mailto:joris AT]
> Sent: Wednesday, July 30, 2003 12:31 AM
> To: LCDproc
> Subject: Re: [Lcdproc] orphan drivers
> 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>
> Mobile: 06 288 41 964
> // To understand recursion, we must first understand
> recursion
> _______________________________________________
> LCDproc mailing list
> LCDproc AT

Archive powered by MHonArc 2.6.18.

Top of page