[Xcb] Thinking towards 7.6 katamari, including xcb

[Peter Hutterer]

On Wed, Oct 28, 2009 at 12:42:40AM -0700, Keith Packard wrote:
> Excerpts from Peter Hutterer's message of Tue Oct 27 23:52:23 -0700 2009:
> 
> > If the drivers aren't pulled in, then the server can trot along slower.
> 
> And that's what's been happening to date; the server loafs along at a
> 6-month to 1-year release cycle. And we get few people running recent
> servers because they've got a lot of changes in them, and they have to
> rebuild and install several modules get the new server working.

Building the server is annoying, I grant you that. All our build scripts
default to build the whole lot, protos, apps, libs, server, drivers.
We're talking about (IIRC) over 100 modules here.

By contrast, the server + the important drivers are 4 packages. Assuming
that ppl have one graphics card and need evdev + synaptics.
Even merging the drivers into the server will not help unless we change the
build scripts to be saner than what they are now. And once you have
unreleased protocol changes, all bets are off anyway.

People don't run recent servers - I expect this is true. But I do think this
is caused by more than just drivers being outside of the tree I doubt.

> > So the real question is - does the benefit of pulling the drivers into the
> > server outweigh the costs of releasing and maintaining multiple server
> > branches?
> 
> At this point, we've got a huge pile of legacy garbage in our driver
> API which is bloating the server and making it difficult to fix some
> problems. We could fix that in the current environment, but that would
> mean getting all of the drivers to follow along while still providing
> backwards compatibilities with old server APIs. Anyone want to do the
> whole RandR 1.2 transition again?

I don't disagree with that.
 
> I'm also unconvinced that X.org needs to maintain a million (or even
> three) server branches, even with a 3-month server release cycle. I
> know an OSV will need to maintain anything they release for long term
> support, but that really isn't something X.org can do for them --
> we're only talking about 6 months vs 1 year in the case of a
> two-release window. A drop in the bucket of difficulty compared with
> back porting patches for seven years. Anyone is welcome to pick up an
> old release and maintain it; I know Greg K-H is still maintaining
> Linux 2.6.27 as it's useful for Novell as a company, after all.
> 
> But, if doing 3 month releases of the whole server tree means that
> we'll scare OSVs away from our project, then I wonder how they manage
> the Linux kernel today. Is the three month cycle a nightmare there? Or
> is it helping them?

OSVs aren't "they". OSVs are "we". Ajax, Alan, Julien, Jeremy to just name a
few. Anything you do that increases the work for OSVs reduces the time we
can spend on upstream.

And comparing the workflow for enterprise distributions such as RHEL and
"normal" distributions such as Fedoras is difficult at best. What works for
Fedora doesn't necessarily not work for RHEL and the other way round. So you
can't really expect that the 7 year backporting of kernel patches translates
to backporting of X patches in the average desktop distro.

> > The decision to merge seems to have been made already, so I guess that
> > question is answered.
> 
> Until we actually merge stuff, we can always revisit this
> decision. Not that I really want to; I'm looking forward to deleting
> more code from the intel driver and the X server. But, I admit to not
> really thinking through the desire to keep shipping drivers frequently.
> 
> There are significant benefits to merging in drivers, the two that I'm
> looking forward to are:
> 
>  1) Bisect server and driver together to find bugs.
>  2) Fixing the API/ABI aggressively.

There's a bonus to stable branches. Any time spent trawling other
distribution's patch sets is time _wasted_. Distributions find similar bugs
but they also find different ones.  Which means with every point release you
get bug fixes from all of them - even for bugs yet to be discovered in your
distro. That is of course assuming patches are upstreamed.

Workflow-wise, updating 1.7 to 1.7.1 is pretty much a no-brainer in Fedora.
Having to cherry-pick patches and maintain them as different patch sets is
more time consuming, takes more effort and is thus less likely to happen.
Which again results in more bugs, more bugs upstreamed, less time for
developers all round.

The two points you mentioned are good for developers, the ones I mentioned
here are good for distros. Unfortunately, the divide isn't that great when
it comes to the actual people doing this, so the more you go into one
direction the more you lose on the other. Where the optimal spot is I don't
know.

Cheers,
  Peter