Re: X.org plans for the squeeze cycle
Julien Cristau wrote:
[other xsf members, feel free to chime in if I'm forgetting something or
saying something stupid :)]
On Sun, Aug 16, 2009 at 14:41:24 +0200, Marc Brockschmidt wrote:
* Which major upstream releases of X.org are expected in the next two
years? Which of those are material for Debian stable, which might be a bit
X.org release management is notoriously pretty bad. Releases often slip
by months, and bugs in .0 server releases aren't unheard of. See also
Anyway, there's no schedule for 1.7 to my knowledge, let alone for the
subsequent releases. I'd guess server 1.7 (and X.Org 7.5) will come
before the end of the year, though, so that seems like a good candidate
for a squeeze release in 2010.
My main worry for 1.7 is that it probably won't give us a lot of time to
shake bugs out of XKB2. We're not historically very good at dealing with
the guts of the input system anyway, and that XKB2 won't provide any
immediate user-visible changes that seem to make it a must have (if I'm
wrong here, please correct me!) On the other hand, with the 1.6 servers
we finally have a stable input system again, so my sense is that we
should probably be conservative and go with the 1.6 branches for squeeze
given our short time frame.
FWIW, the pattern so far looks like:
Apr 19 2007 xorg-server-126.96.36.199.tar.gz
Sep 6 2007 xorg-server-1.4.tar.gz
Jun 10 2008 xorg-server-1.4.1.tar.gz
Jun 11 2008 xorg-server-1.4.2.tar.gz
Sep 3 2008 xorg-server-1.5.0.tar.gz
Sep 23 2008 xorg-server-1.5.1.tar.gz
Oct 10 2008 xorg-server-1.5.2.tar.gz
Nov 5 2008 xorg-server-1.5.3.tar.gz
Feb 25 12:19 xorg-server-1.6.0.tar.gz
Apr 14 13:09 xorg-server-1.6.1.tar.gz
Jul 7 16:39 xorg-server-1.6.2.tar.gz
Jul 31 23:42 xorg-server-1.6.3.tar.gz
* How much time do you usually need from a new upstream release of X.org
to a stable Debian package in unstable?
I'd say 6 months to a year from a .0 server to something we can ship in
stable. Depending if RedHat/Fedora are shipping it too and thus fixing
most bugs for us.
* How many "big" transitions will the upcoming changes cause? When should those
happen? Can we do something to make them easier?
Lately the big problems were related to the stability of the intel
driver, which went through several big changes (full modesetting in the
driver instead of using the bios, then switch of acceleration
architecture to EXA, then a kernel memory manager, then kernel mode
setting, and I'm probably forgetting some). Hopefully most of that is
over, and we can migrate it to testing soon along with the rest of the X
Kernel mode setting for the radeon driver is being worked on, will be in
staging in the 2.6.31 kernel, so hopefully we can ship that stack with
squeeze. The nouveau driver is also lining up for inclusion in the
kernel (maybe in staging in 2.6.32?) so it'd be really great to be able
to ship that in the release, too.
Some of that depends on having enough people available to package new
releases, triage/forward bugs, and test the new stuff. I won't be able
to do much of that myself in the foreseeable future.
This is the big one to me. I don't interface at all with the
debian-kernel folk, and have no idea what their plans are. Given the
user demand that I've seen, I'd much rather throw whatever effort we can
in to providing optional KMS bits for radeon, as well as high quality
intel, than worry about XKB2 and Xserver 1.7. I don't know that we'll
have the manpower to do that either, but this seems to be where we'll
get the most payoff for our energy.
One thing that might cause some minor disruption in sid is the moving
around of headers between libxext and x11proto-xext
Fedora already went through that, though, and the change should be
mostly invisible to clients.
I don't really know what to think about this.
- David Nusinow