Xserver driver merging pros & cons

[Peter Hutterer]

On Thu, Sep 15, 2011 at 01:46:30PM -0500, Jeremy Huddleston wrote:
> 
> 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.

wacom is GPL but definitely not a second-class driver. unless we're willing
to take on the hilarity of discussing GPL-ing the server merging the input
drivers is pretty pointless - the driver that needs it the most get's the
least benefits.

which - for now - at least rules out input driver merging. evdev and
synaptics could benefit from some shared code but the effort involved and
the potential loss of testers against old releases make me shy away from it
right now.

Cheers,
  Peter

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