[Xcb] Thinking towards 7.6 katamari, including xcb
keithp at keithp.com
Wed Oct 28 00:42:40 PDT 2009
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
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.
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091028/eb40c12b/attachment.pgp
More information about the xorg-devel