xserver ABI freeze policy

Aaron Plattner aplattner at nvidia.com
Tue Apr 29 10:47:12 PDT 2014

On 04/29/2014 09:58 AM, Keith Packard wrote:
> Mark Kettenis <mark.kettenis at xs4all.nl> writes:
>> We're changing the ABI to fix a mistake made earlier in the release
>> cycle.
> Right, the ABI change was just fine, but the fact that the related API
> change broke essentially every driver in an 'undetectable' way
> (generating just a warning, which most people are well trained to
> ignore) meant that we really needed to address this as a bug in the X
> server and not just bugs in individual drivers.
>> But if Aaron/NVIDIA really wants to stick to the current ABI, I'd say
>> they should do the work of fixing and testing all the open source
>> drivers.
> Aaron has been good about noticing ABI problems like this in the past
> and working to find a solution that is acceptable for everyone. As
> release monkey, I feel that one of my responsibilities is to respect the
> historical perspective of the project towards non-free software, and in
> this case, making it possible to release binary drivers is part of that.
> We've made a commitment to preserve the driver ABI and API once the
> feature freeze hits, and in this case we've found a bug that can only be
> addressed by breaking that commitment. We should work to find a way that
> can address this bug in a way that minimizes the impact to all of our
> users, even those who hold their noses and run non-free drivers.

Thanks, Keith.  I think in this particular case the API could actually 
be fixed while preserving the ABI, but I'd like to make that point moot 
with the following proposal:

1. I agree that freezing the ABI multiple months in advance is too long; 
we don't need *that* much time to get a release tested and out the door. 
  Let's change the official ABI freeze policy to 4-6 weeks before the 
final release for each release cycle.  So I guess either the last or 
second-to-last RC would be the official ABI freeze date?

I won't promise same-day support for new X servers, but that lead time 
should at least let us get close.

2. For reasons I won't get into, it looks like I'll be able to sneak in 
a last-minute revert of my "ABI 17" support changes into our next driver 
release, so it won't claim xserver 1.16 support.

3. I won't care about this particular ABI change for now, and will 
reevaluate when the official ABI freeze is declared.  I don't care 
whether that gets called ABI 17 or 18 or whatever.

Does that sound reasonable?  Someone from AMD should chime in if they 
care about this too.


More information about the xorg-devel mailing list