Sidebar to: Xserver driver merging pros & cons
davecb at spamcop.net
Thu Sep 22 09:55:27 PDT 2011
Alex Deucher <alexdeucher at ...> writes:
> On Thu, Sep 15, 2011 at 1:17 PM, Keith Packard <keithp at ...> wrote:
> > On Thu, 15 Sep 2011 12:34:51 -0400, Alex Deucher
> <alexdeucher at ...> wrote:
> >> The number of ABI breaks is minimal (usually 1 per
> >> xserver) and those can usually be fixed within a day or so of the
> >> breakage.
> > We don't get ABI changes because they're nearly impossible to handle.
> >> I don't rebuild the xserver nearly as often as I rebuild
> >> the ddx so it would mean more work to keep up with the xserver changes
> >> on a regular basis.
> > On the plus side, we'd get a whole lot more coverage of new X server
> > betas before release...
> True, but on the other hand, we'd probably get less testing against
> random older X servers.
> xorg-devel at ...: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
You can deal with ABI evolution via a controlled process of versioning, but the
people working out-of-tree have to *want* to evolve with you. If they don't,
they'll fall off, just not instantly!
I'm actually of the opinion that it's more valuable for in-tree work, when the
developers are only likely to be a bit out of synch with each other.
A lightweight description of mutating an ABI is in the Paul Stachour ACM
--dave (I was his editor) c-b
More information about the xorg-devel