Xserver driver merging pros & cons

[Alan Coopersmith]

On 09/15/11 14:01, Jeremy Huddleston wrote:
>
> 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:
>>>>  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.

If you're talking enterprise distros though, that means committing to at least 
one long-term support stable branch, that you backport new driver support to
for years, not just the 6 months until the next one.

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System