Xserver driver merging pros & cons

Jeremy Huddleston jeremyhu at apple.com
Thu Sep 15 11:46:30 PDT 2011


On Sep 15, 2011, at 11:02 AM, Michel Dänzer wrote:

> 3) Out of tree drivers will become second class citizens.

I don't see that as a con.  I see that as a benefit.  If something is not in the tree, it IS a second class citizen, and users should not expect it to work any more.  If the trident driver breaks, they can always use vesa.

> This doesn't
> apply to proprietary drivers only but also e.g. to the Gallium xorg
> state tracker, which we may want to use for Radeons at some point (and
> some nouveau people have been playing with it as well, but I don't know
> what their plans are for it).

As someone without much experience with the Gallium xorg state tracker, I'm curious what technical hurdles prevent you from using it as a library linked against by the x11 driver.

> Speaking as a radeon driver developer, merging the driver into the
> server tree would be unworkable at this point because since the "new
> development model" has been in effect, it's not possible to get even
> trivial changes into the server tree without a ridiculous amount of
> time/effort.

Can you be more specific?  When we were discussing this yesterday, it seemed like the "new development model" was working and that it was no longer a barrier to this problem.  The longest you will go to get in to a stable release is 7 weeks.  That is in the rare case that you have it ready immediately after the release of rc2 and you really want to use a stable release version.

Instead of pushing your changes to xf86-video-ati, you would push them to xorg-server-ati and when ready send [PULL] emails to the manager for the branch you want your changes to land in.

Looking at the xf86-video-ati git repo, I was shocked to see that you really only have master and don't use separate branches for old stable releases.  IMO, transitioning to a code management paradigm of development versus stable branches would be a win for you and your customers because you can do more experimental changes in master and just cherry pick support for new hardware and general bug fixes into the stable branch.




More information about the xorg-devel mailing list