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