Xserver driver merging pros & cons

[marcoz at osource.org]

Do distro's share testing?  I've seen comments on how testing diff 
versions of drivers against diff versions of the X server and having to 
deal with problems there. Can some of that be offloaded from the distros 
into Shuang He's auto-regression testing setup?  I realize how that will 
grow in complexity testing Xserver vX with radeon vY with libblah vZ and 
it wouldn't catch subtle things like default changes but
could it be used to catch obvious things before the distros do?

Shuang, I missed the first part of your presentation so I'm not sure if 
you covered that.

Matt


On 09/17/2011 12:24 PM, Keith Packard wrote:
> On Sat, 17 Sep 2011 13:04:13 +0200, Matthieu Herrb<matthieu.herrb at laas.fr>  wrote:
>
>>     3) makes it harder to maintain out of tree drivers, since API
>>        breaks are not going to be documented anymore.
>>        If old pre-kms code start to be removed, the people still
>>        depending on them will need a forked X xserver, which is not a
>>        good idea at all.
>
> Our current ABI change process is to find out when someone tries to run
> a driver which hasn't been recompiled against the development
> server. For changes which don't affect the API, that's often been Aaron
> Plattner, who maintains an out-of-tree driver.
>
> The ABI numbers live in a 16-bit space, and we've only used a tiny
> portion. I think we should feel fairly free to bump the ABI number
> anytime something changes, and not just once per server release.
>
>
>
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel