[Xcb] Thinking towards 7.6 katamari, including xcb

[Alex Deucher]

On Wed, Oct 28, 2009 at 3:42 AM, Keith Packard <keithp at keithp.com> 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.
>
>> 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'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?
>
>> 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.

While, I'd like to delete a lot of compat cruft in the drivers as
well, I'm concerned about lack of user testing if we merge the driver
back into the server.  Right now it's pretty easy to get users try a
patch, or the latest git changes, but requiring them to rebuild the
whole xserver is a pretty daunting task, especially if various build
requirements change along the way. If that's the case, it kind of
negates the usefulness of being about the bisect the server and driver
together.  So I think the main issue here is making building the
xserver less daunting.

Alex