Sidebar to: Xserver driver merging pros & cons

[Peter Hutterer]

On Thu, Sep 22, 2011 at 04:55:27PM +0000, David Collier-Brown wrote:
> 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

ABI versioning helps, but it somewhat requires that you actually have a
defined ABI and you know what parts of your code are ABI. Our history of
"any header we install is ABI" doesn't make that particular part easy and
changing that is a huge task.

Cheers,
  Peter