"Mike A. Harris" <mharris@www.linux.org.uk> wrote: > >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. Actually my comment above probably didn't read the way I intended. What I was trying to say is that the current mechanism employed by the XFree86 core team is one way to try and minimise the impact of driver bugs. But as you point out, this assumes that the committers have some way to verify that the code actually does work. About all they can really do is verify that it compiles, since I doubt the committers would have access to the breadth of hardware necessary to do real conformance testing when they commit patches (and hence the reason I said people probably have nightmares about stuff breaking and are reluctant to include patches!). > >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. No, I was not implying that as I seriously doubt committers have access to the hardware necessary to do this ;-) > >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. Yep. You hit the nail on the head with that one. We have solved that particular problem very cleanly with our SciTech SNAP Graphics product, but I have beaten that horse to death before on the XFree86 list and Linux kernel list, and I don't plan to beat it again ;-) > 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. Yes, that I would agree with. Unless you have formalised testing and release prodedures in place for binary driver modules, the above is about the best you can do to ensure correct drivers (and it has worked reasonably well for the Linux kernel). > 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. Yes. The driver DDK and source code should be completely separate, build separately and be testable separately. That would allow developers to work on the drivers independantly of core XFree86 releases, and drivers could be released on a different schedule to core XFree86 releases. Then it would not matter if there is 6 to 12 months between 4.3 and 4.4, so long as frequent driver updates are available during that period of time. Of course this presents a *huge* number of logistical problems that need to be solved, such as who tests the drivers with each version of XFree86, who maintains the 'master list' of drivers that distros can distribute etc etc. But those problems are solveable. 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! ~