Re: Some perspective from the cheap seats...

On Thu, 20 Mar 2003, Kendall Bennett wrote:

>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. 

Restricting access to CVS doesn't guarantee the drivers are
working or that any of them have even been tested with any test
suite.  The "cyrix" driver was quite broken for a couple of 
releases for example.

With the existing "core team", changes *do* get checked into CVS 
that *do* break things too.  The savage driver being one example 
(Dec 16th checkin) which broke the savage driver on Savage MX, 
and obviously was not tested on real hardware.  It also wasn't 
fixing any real bug.  This clearly shows that even the core team 
can check in bugs that break hardware also, and often do (or 
there wouldn't be any bugs right?)


>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.

I hope you're not implying that the core team does that right now
for every checkin, as I rather doubt that that is the case.


>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.

That is a rather difficult proposition actually.  Neither the 
core team, nor any other developer out there is likely to have 
_all_ of the hardware that a given driver supports.  I doubt that 
any developer would be willing to make a driver change, and then 
test the driver in all resolutions and color depths on every 
piece of hardware that the driver supports even if they _did_ 
have all of that hardware.  It is just too time consuming and 
non-practical, in particular considering it is generally 
volunteer effort.

What needs to be done, is for driver developers and contributors 
to test their modifications on as much hardware as possible, and 
for frequent "test drivers" to be made publically available so 
that the swarms of users out there can test them on a much wider 
variety of hardware.  Without "release early, release often" beta 
testing, what we get is 12 month releases with many after the 
fact bugs reported by users, many of which wait another 12 months 
before an official fix is incorporated into a stable release.

IMHO, if the drivers are separated from the core server releases, 
the drivers can be updated much more frequently, both with in 
between beta tests of which each driver can be developed on it's 
own time schedule, and the final drivers will get more testing 
and usage on shorter time schedules also, al while the core 
server development progresses on it's own cycle.

IMHO that would improve both the quality of the drivers as well 
as allowing more frequent bugfix updates, and support for newer 
hardware to not lag hardware release by 12 months.


-- 
Mike A. Harris