Re: Some perspective from the cheap seats...

"David Wexelblat" <[email protected]> wrote:

> - I believe we do need more committer access. Not open access, but more
> committer access. Mostly to reduce load on the people who are currently
> responsible. I believe this is already in progress.

On of the key issues that I see at work here, is something I brought up 
quite a few years ago now. XFree86 desperately needs a suite of 
conformance tests that can be used to validate that a driver module is 
correct and the binary interfaces are functioning properly. The loadable 
module system is a step in the right direction, but simply compiling all 
the modules and releasing them as a single lump for every XFree86 version 
is inviting trouble. Unless someone has a change to sit down and 
physically test the driver modules on all 'supported' hardware, there is 
a very good chance that things will break.

Which brings me to the point about committer access. IMHO the XFree86 BOD 
and Core Team have nightmares about driver bugs due to this exact reason. 
Someone needs to police changes made to device driver code to ensure 
things are *working*, when they are comitted to the XFree86 code tree. 
Keeping the list closed helps to maintain a reasonable amount of quality, 
but it means things move *very* slowly. 

If XFree86 does open up access to more committers (regardless of whether 
it is fully open or just signing up 10-20 more active committers), 
something needs to be done to ensure that people committing the code 
changes can verify things are correct. More importantly those tools 
should be available to the developers actually working on the drivers, so 
they can ensure their work is correct before sending it to the committer.

But, this is just the way I feel. I said this years ago on the XFree86 
developer lists, but no-one really listened to me. As Linus says, actions 
speak louder than words, and for the last few years myself and my company 
has been implementing exactly what I have spoken about above. SciTech 
SNAP drivers are binary portable modules, but we have also build complete 
conformance test suites to ensure the compatibility and integrity of the 
drivers we build. IBM licensed this technology 3 years ago to solve 
theirOS/2 display driver compatibility problems, and we are nearly done 
porting the technology to the Linux platform. We should be going to beta 
in the next week or so for our SNAP Graphics for Linux (XFree86 4.x 
module based), so maybe then people will understand what I was trying to 
get at all those years ago.

> On The Future Of X
> ------------------
> A number of people has questioned the relevence of X in general. To be
> perfectly honest, I'm one of them. I've even pissed off Keith and many
> others on the Core Team by pointing out that X is obsolescent. I've been
> working in the Windows world for years now, and client-server display
> systems are utterly irrelvent to the majority of real-world computer users.
> X needs to be replaced by a direct-rendered model, on which a
> backwards-compatible X server can be reasonably trivially implemented.

Yes, I agree entirely with that. Network transparency is nice sometimes, 
but not really essential for the day to day use of desktop computing. The 
first step IMHO is to simply implement a 2D direct rendering system to 
increase performance. Whether X needs to go or whether it can be 
reinvented to support 2D direct rendering is a different question.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~