On Wed, Oct 28, 2009 at 11:04, Bryce Harrington <br...@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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel