X server 1.9 release thoughts

[Dan Nicholson]

On Tue, Apr 6, 2010 at 11:29 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote:
>> First off, thanks to everyone involved in the 1.8 release; it was a
>> pleasure to work with you. I'm hoping everyone else is as happy as I am
>> about our new release process, it seemed to me that we saw a lot more
>> active review and discussion about proposed patches this time around.
>>
>> For version 1.9, I'm planning on doing things in much the same way, if
>> people have suggestions on how we can improve things, please post them
>> so we can get things settled before we get too far into the release.
>>
>> Ok, so now for the details about the 1.9 release itself.
>>
>> First off, I'd like to get a start on making things easier to build
>> for people interested in testing the server or new drivers. I'm still
>> interested in getting drivers pulled back into the server itself at some
>> point, but it seems like an important and trivial first step will be to
>> merge all of the protocol headers into one package. I'll get started on
>> that and post a pointer to a merged repository for review.
>
> I'm just replying here so we've got my opinion public and archived rather
> than spread across several IRC conversations.
>
> From the input drivers POV merging them in provides little benefit as of yet
> and would probably be even detrimental to testing.

One of the big advantages of putting the input drivers in the same
repo would be the ability to refactor common functionalities like
mouse button emulation into the server. One of the things I'd like to
see happen over time is the input properties becoming less driver
specific. E.g., I'd much rather make use of the property "Middle
Button Emulation" than "Evdev Middle Button Emulation". This would
seem to occur much easier when the server and drivers can be
refactored simultaneously.

> Right now, the drivers that matter build against several X server versions
> and I get testing of e.g. evdev master against older servers, finding
> evdev-specific bugs during the development cycle. This is mostly due to the
> input drivers being much simpler and easier to install than video drivers,
> they have virtually no dependencies.
> The work needed to support multiple server versions is mostly negligible.
> To get the same exposure of testing once the drivers are merged into master
> requires a lot of cherry-picking on my behalf.
> Even then, we'd still need users to install the server + dependencies to test
> a new evdev patch, something which at this point would likely be a
> deterrent.
> So at this point, merging drivers in would increase my workload and reduce
> testing exposure.  That's why I'm reluctant for evdev and synaptics to be
> merged, even though the "no API/ABI" is tempting. The drivers just don't
> move enough to make it worthwhile just yet. We'll see how Benjamin's
> multitouch efforts will affect that.

In the near term that would hurt you because you'd have the modular
evdev built against older servers and the monolithic evdev in the
newer server. So, testing over multiple servers and porting fixes
would be a pain.

Longer term, I can't see it being that big a deal. If a person says
that they're having a problem in a stable release, you check out and
build the stable server with the _exact_ driver they're using and find
the bug. It would seem to make hunting bugs easier since you can have
basically an exact copy of the software they're running in one repo.

Porting fixes from one driver version to the other would still be a
cherry-pick forward or back, just like if you were fixing a bug in the
server. If they're on a really old server/driver combo, tell them to
upgrade. If someone came to you with a xorg-server-1.6 bug right now,
would you attempt to fix it? I'd guess you'd tell them to try a newer
server. That advice wouldn't change if the bug happened to be in the
evdev driver bundled with that server.

Just my opinion. Obviously, you're the one who's going to take the
burden here or not.

--
Dan