Sidebar to: Xserver driver merging pros & cons
David Collier-Brown
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.
>
> Alex
> _______________________________________________
> 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
article at
http://cacm.acm.org/magazines/2009/11/48444-you-dont-know-jack-about-software-maintenance/fulltext
--dave (I was his editor) c-b
More information about the xorg-devel
mailing list