Xserver driver merging pros & cons

[Jeremy Huddleston]

On Sep 15, 2011, at 3:30 PM, Chase Douglas wrote:

> 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.

No, I'm not placing the burden on the distros to do all the work.  It's X.org's responsibility to ensure that relevant fixes land in our stable releases.  Fixes that add support for new hardware in an unobtrusive way and changes which fix real bugs are great candidates for cherry-picking into the stable branch.  If a distro wants something even earlier, they can cherry-pick it themselves, but this is no different than pulling in changes from an unreleased driver currently.  Driver maintainers will have their own xorg-server tree living on github, git.fd.o, or whatever, and we'll merge changes from there into xserver.

> 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.

Yes, I think I'm saying the latter.  Users and distros have the benefit of knowing that this tarball / tag contains bits that all work together.  Distros like Gentoo won't need to do weird version blocking in each ebuild stating which version of the server each driver works on.

> However, it does sound
> like some want to shift the burden of maintenance.

It does shift burden of maintenance onto the xserver stable release manager (currently me) to wrangle driver developers into getting relevant changes into the stable branch.

I don't see it as adding to much burden on distros.  There will be startup cost associated with updating rpm specs, ebuilds, Portfiles, or whatever you use for package management, but once that is done, the process is pretty much the same.  

Currently if you find out that the new driver 2.20 doesn't work with server 1.7, what do you do?  You figure out how to patch driver 2.20 to work with the old API and submit patches to the driver maintainer.

Now, if it turns out that server 1.11.3 doesn't support the new ATI chipset with support that just landed in master, you either wait for 1.11.4 or you pull in the patch yourself.  This is the whole purpose for distros, so I don't see it as a real burden.

> 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.

Yes, but as others have mentioned, API changes across server versions are currently minor enough that it's easy to fix.  This indicates to me that backporting a change from master to an older server would be equally minor.  You just cherry-pick the change and fix API changes.  Most changes will either be obvious as to how to address the issue (probably new hardware support where you look at how it was done in the other hardware and adjust the API) or are small enough bug fixes that they don't need any changes after cherry-pick.

> Personally, I would prefer a monolithic tree with separate branches for
> backporting driver changes to older server versions.

Yes.  That is what I think is ideal.

> 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.

I also think that it would be valid to extend the life of the stable branches to include the previous two release series in order to allow for this.  Each stable release branch would have a roughly 1 year life rather than the current 6 months.  We can even go longer (or even git-only after some point) if that would be helpful to distros.  I don't mind cherry-picking good fixes into older branches.  I just stop because I don't feel going back too far is particularly useful.  If we had consensus on what the line should be, we can adjust to it.

> 
> 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