[Xcb] Thinking towards 7.6 katamari, including xcb

[Daniel Stone]

Hi,

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:
> > 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?

No doubt -- as I said, this is one of the best arguments for merging the
drivers into the server.  You can't even call our collection of rubbish
header files an API with a straight face, and that needs to be fixed at
some stage, so.

> 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?

OTOH, we are not the kernel.  OSVs currently throw large amounts of
development time at the kernel because they know how it works and they
expect that they have to put in that much work.  Right now, they take
stable X trees, and expect them to work and at least be loosely
maintained into the future.

Red Hat are the exception to the rule here.

If we want to change this and say that once a release is made, you can
use it if you want and we guarantee that it won't bitrot or actively get
worse, but beyond that you're on your own ... well, we can do it.  But
it's a huge change from what we have now (releases we make are actively
supported for bug fixes etc well beyond their release date), and I think
it's one that should be discussed, given that it was never even
mentioned at XDC, nor on the list.

The sole motivation for this seems to be making driver maintainers'
lives easier (which is no bad thing), and giving hardware vendors a
shorter time-to-market for hardware enables.  Is there anything stopping
you from backporting your hardware-enable code to at least the last
stable release (i.e. 6 months old), and shipping a point release? The
hardware-enable diffs I've seen from the Intel driver seem to be quite
small indeed, so I get the feeling this wouldn't be a huge burden on you
guys, and it would also prevent the detrimental effects a lot of the
server hackers feel we'll see with a vastly reduced cycle.

It would be nice to see what the distros think about this, too.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xcb/attachments/20091028/7d712eeb/attachment.pgp