Sidebar to: Xserver driver merging pros & cons

[David Collier-Brown]

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