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.

-- 
Aaron


More information about the xorg-devel mailing list