[Xcb] Thinking towards 7.6 katamari, including xcb

Stephane Marchesin marchesin at icps.u-strasbg.fr
Wed Oct 28 03:07:15 PDT 2009


On Wed, Oct 28, 2009 at 11:04, Bryce Harrington <bryce at canonical.com> wrote:
> On Wed, Oct 28, 2009 at 07:39:41PM +1100, Daniel Stone wrote:
>> On Wed, Oct 28, 2009 at 12:42:40AM -0700, Keith Packard wrote:
>> > 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.
>>
>> 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.
>>
>> It would be nice to see what the distros think about this, too.
>
> For Ubuntu, it is more the timing and predictability of the releases
> than their frequency.  If it were timed right, a 6-month cycle that
> releases right before our feature freeze date would be about perfect.
>
> But the problem is that what may be perfect for one distro may be too
> early or too late for another distro.  This is where a 3-month cycle
> could have some advantage.
>
> We've seen some of this benefit in Intel's release cycle.  We get a
> release N which is early in our development cycle, and another N+1 which
> typically comes in well past feature freeze.  Since the difference
> between N and N+1 is only 3 months, we could just ship N and not feel
> guilty about it.  Or, if N+1 is mostly a bug-fix release, and in our own
> testing we find it super solid, we can pull it in even really late
> without feeling we're taking too big of a risk.
>

Or, as others suggested, you (distro vendors) could hire people
knowledgeable about X/driver internals and maintain/backport your own
stuff. This is the core of the problem here, there is no such thing as
a free lunch...
I'm afraid here more releases will shift even more burden on
understaffed X.Org teams.

Stephane


More information about the xorg-devel mailing list