[Xcb] Thinking towards 7.6 katamari, including xcb

[Keith Packard]

Excerpts from Daniel Stone's message of Wed Oct 28 01:39:41 -0700 2009:
> 
> 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.

Let's look at our release pattern.:

2005-12	   1.0.1

2006-05	   1.1.0
2006-07	   1.1.1

2007-01		1.2.0
2007-04			1.3.0
2007-08				1.4.0

2008-06	   			1.4.1
2008-06	   			1.4.2
2008-09					1.5.0
2008-09					1.5.1
2008-10	   				1.5.2
2008-11	   				1.5.3

2009-02						1.6.0
2009-04						1.6.1
2009-07	   					1.6.2
2009-07	   					1.6.3
2009-09	   					1.6.4
2009-10							1.7.0
2009-10	   					1.6.5
2009-10							1.7.1

If one argues that 1.4.2 was really another major release, then the
only 'long term' support we've ever done has been with 1.6. Now, I'm
not saying that long term support is a bad idea, but we really haven't
managed this yet.

> 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 development effort here is minor, the big difference is
testing. And, right now, we're only testing our releases against the
latest stable X server release, so having it work against older
releases is purely a happy accident.

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

With the bulk of the hardware support now in the kernel, this is
probably even more true now than in the past. Of course, that doesn't
eliminate the testing burden, which almost doesn't care how small the
changes are if it requires yet another full set of tests to validate
hardware support in an older release.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xcb/attachments/20091028/e754be01/attachment.pgp