Xserver driver merging pros & cons

[Chase Douglas]

On 09/15/2011 01:00 PM, Jeremy Huddleston wrote:
> 
> On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote:
> 
>> On Thursday 15 of September 2011, Jesse Barnes wrote:
>>> At XDC this week we discussed merging drivers back into the server
>>> tree.  One thing I found frustrating about the discussion was that we
>>> didn't have a whiteboard nor a list of the pros & cons of such a
>>> change.  So I'd like to capture that here (from memory) to let us
>>> continue the discussion about whether it's worth it or not.
>>
>> From distro package maintainer point of view I _love_ split drivers. It's so 
>> much easier to packages these, rebuild when needed (one faulty, not building, 
>> driver doesn't stop whole build process), easier to patch and backport fixes.
> 
> I don't see how it is easier.  git-cherry-pick should do most of that for you just like it currently does.  You'd just be doing it in a clone of xorg-server rather than a clone of xf86-video-*

I think this is mixing two issues. Yes, cherry picking individual
commits to get a "newer" driver that still works with an older server is
not terribly difficult. However, you seem to be advocating that the
consumers (distros) should do this. Currently, X.org is doing this by
providing upstream drivers that work against multiple server versions.

Maybe you're not really suggesting a shift of maintenance from X.org to
distros. You might be saying that it will be trivial for X.org to
cherry-pick commits and provide multiple upstream driver releases with
latest hardware support for multiple servers. However, it does sound
like some want to shift the burden of maintenance.

The maintenance burden and the mechanisms of maintainence can be
completely separated:

* A monolithic tree with separate branches for backporting new driver
support to older servers
* A monolithic tree with only one branch, but each driver has #defines
and such for supporting different server versions
* Split trees with separate drivers, each tree has separate branches for
backporting new driver support to older servers
* Split trees with separate drivers, but each driver has #defines and
such for supporting different server versions (which is what we have now)

Each approach then also has its own defined burden of maintenance. Will
X.org provide the commits/patches/branches required to maintain a driver
across server versions? Will distros have to carry this load (even if
the end result lives on freedesktop.org)? Will it vary between drivers?

I know this is getting farther away from the original topic of
monolithic or separate trees, but the can of worms was opened when one
of the "pros" of monolithic was potentially removing support for older
servers in at least the master branch.

Personally, I would prefer a monolithic tree with separate branches for
backporting driver changes to older server versions. I would also prefer
each driver having a stated policy of how many back revisions of servers
are supported by upstream X.org. This would allow the distros to stay on
a given server branch, still receive upstream driver updates, and ensure
there is an understanding of the level of support for each individual
driver. Also, it would keep each branch clean of the server abi #ifdefs
and whatnot, including in back server branches.

Note that I'm speaking here with my personal developer hat on. Bryce
Harrington and Chris Halse Rogers would be better to chime in on
Canonical support for Ubuntu, but I imagine that it really doesn't
matter too much to us because we tend to stay near the bleeding edge.

-- Chase