|
|
Log in / Subscribe / Register

The Xorg 7.4 release plan

[Posted February 27, 2008 by corbet]

From:  Adam Jackson <ajax-AT-redhat.com>
To:  xorg-AT-lists.freedesktop.org
Subject:  Xorg 7.4 release plan
Date:  Tue, 26 Feb 2008 14:06:52 -0500
Message-ID:  <1204052812.979.36.camel@localhost.localdomain>

Right, we've been slackers for a bit here, it's time to ship something
that works.  My motives are not entirely altruistic here, I really want
something that isn't a git snapshot in Fedora 9, but we're way past the
initially projected release date by now [1], so it's time to shape up
anyway.

Since I'm aiming for F9, the schedule proposed below is designed to work
with that constraint.  The schedule for F9 is here:

http://fedoraproject.org/wiki/Releases/9/Schedule

Briefly summarized as:

March 4: Feature freeze
April 8: Development freeze
April 22: Release candidate
April 29: Final release

Like all schedules, this is probably optimistic, there's probably two
weeks or so of slip in there.  But it makes for a pretty good timeline,
so we'll stick with it.  Astute observers will note that those dates are
all Tuesdays, so to give some slack time between X snapshots and
downstream, I'd like to move our deadline dates to the preceeding
Fridays:

February 29: Branch 1.4.99.901, no new features
March 14..21: .902, enter code slush, review if unsure
April 4: .903, freeze, approved fixes only
April 18: .991, hard freeze, showstoppers only
April 25: xserver 1.5 and 7.4 katamari

Those of you watching the xorg-team@ alias may have noticed a recent
flurry of blocker bug nominations.  The blocker bug for 7.4 is:

https://bugs.freedesktop.org/show_bug.cgi?id=10101

There's a lot of stuff on there.  Much of it should not be difficult to
fix, given the existence of either a reproducer or a proof-of-concept
patch.  If you have bugs that you think should be blockers, please add
them to the bug.

Outside the blocker, there are several outstanding issues that, in my
mind, need to be addressed in one form or another before 7.4.

pciaccess is not done.  We still have ~20 drivers that haven't been
ported, and some of them are not quite trivial to convert.  This needs a
champion in a serious way.  I'm convinced enough of pciaccess' value
that I don't intend to revert it for 7.4, but we need to make progress
here.

Input is not stable.  Since the last time I rebased X in fedora, I've
had complaints about inability to switch keymaps, broken control-alt-foo
combos, stuck axes on mice, keymap changes disappearing at runtime, etc.
We never shipped 1.4 in fedora, but afaict XKB was fairly broken there
too.  I'm really loathe to revert XKB to its 1.3 implementation, but in
the absence of fixes, I'll do what needs doing.  Likewise input hotplug
needs a sensible transition plan before I can really ship it.

The X-SELinux work is not viable yet.  I'm fine with leaving it in place
and simply configuring it off by default, but there's both not enough
good policy and too many remaining implementation bugs to consider it as
is.  Starting gnome-session should not throw BadWindow.

RANDR 1.2's initial configuration heuristic is garbage.  I'm working on
this as I get time, and I hope to have something better by the end of
the week, but I can't ship the current heuristic with a clear
conscience.

These are just bugs.  They're fixable.  And we need to fix them.

In light of discussions about various people's time commitments at LCA,
I'm going to be taking the release manager role for this one, with Eric
and Daniel acting as deputies for things like patch review.  My interest
is primarily in the server component; driver maintainers, if there's a
specific branch I should be looking at for 7.4 inclusion, please notify
me, otherwise I'll assume releases should happen from git master.

Questions?  Comments?  Favorite burger topping?

- ajax

_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

to post comments

The Xorg 7.4 release plan

Posted Feb 27, 2008 16:33 UTC (Wed) by pr1268 (guest, #24648) [Link] (8 responses)

As much as I admire Xorg's diligence in releasing new versions, I'm a little concerned about how they're targeting a release date based solely on some Linux distro's release (i.e. Fedora 9). Seems a lot of defects slip through the cracks when hard deadlines approach (a broad generalization, for sure), and considering Xorg has little influence on the F9 release date, then they'd likely push out whatever they have on that day, regardless of quality.

Okay, I admit that was curt, and perhaps blatantly wrong on two levels (someone please correct my statements above or below):

  1. I suppose Redhat/Fedora employs a lot of Xorg developers, so they could influence each other's release date, and
  2. The quality and reliability of Xorg's software is quite good these days, so certainly they're prepared for the release.

Congratulations to the Xorg development team for maintaining a lively release cycle.

The Xorg 7.4 release plan

Posted Feb 27, 2008 19:08 UTC (Wed) by i3839 (guest, #31386) [Link] (1 responses) 

> we're way past the initially projected release date by now [1],
> so it's time to shape up anyway.

He just forgot to link to the original schedule. But it seems they basically just missed the
first deadline, and now are using another one to keep up the motivation. ;-)

The Xorg 7.4 release plan

Posted Feb 27, 2008 19:20 UTC (Wed) by i3839 (guest, #31386) [Link] 

Update:

From: Adam Jackson <ajax <at> redhat.com>
Subject: Re: Xorg 7.4 release plan
Date: 2008-02-27 18:53:34 GMT (23 minutes ago)

On Tue, 2008-02-26 at 14:06 -0500, Adam Jackson wrote:
> Right, we've been slackers for a bit here, it's time to ship something
> that works.  My motives are not entirely altruistic here, I really want
> something that isn't a git snapshot in Fedora 9, but we're way past the
> initially projected release date by now [1], so it's time to shape up
> anyway.

D'oh.  All that and I forgot to footnote the original release plan.

http://xorg.freedesktop.org/wiki/Events/XDS2007/Notes#hea...

I should make a note here of what we had initially targetted for 7.4,
and what I think the current status of each is.  So.

XGE probably not going to make it, Peter's schedule isn't particularly
friendly and iirc we didn't think it was ready at LCA.  XACE is merged
and pretty well ingrained by this point; the subsequent X-SELinux
extension looks like it's making good progress (thanks Eamon!).  RANDR
1.3 ain't happening.  Input transformation ain't happening.  pciaccess
is in.  XKB 2 isn't.  Enforcing server ABI with linker scripts (the
cryptically named "_X_EXPORT" in that list) isn't done but is pretty
straightforward; I'd happily take a patch if one showed up, otherwise
I'll see if I can work it in.  The DRI memory manager work and GLX 1.4
are more or less in, afaik, and we'll just have to figure out a Mesa
build solution to make them happen.  Glucose ain't happening.

So, ten things targetted, four included, one probable.  50% feature
completion per release seems to be about par for the course for us, no?

- ajax

Time-based release actually works well

Posted Feb 27, 2008 19:14 UTC (Wed) by dwheeler (guest, #1216) [Link] (4 responses)

It's not necessarily a bad idea. Indeed, changing your schedule so that it meets your customers' is a good idea, and most people use X.org from a distro - not directly.

But more importantly, Martin Michlmayr (Debian developer and formerly Debian Project Leader) is completing his doctoral thesis at the University of Cambridge with a thesis entitled “Quality Improvement in Volunteer Free, and Open Source Projects: Exploring the Impact of Release Management. He argues that time-based releases (e.g., where releases reliably happen every 6 months) is actually a reasonable approach. In FLOSS, you can typically decide what to include - or not include - on a particular date, depending on what's ready. By having a date, people can try to get the various bits ready... and if a snag happens, omit that part.

GNOME already uses this approach. So if X.org can switch to this in general (not just have a one-off deadline), it'd be good for all.

Time-based release actually works well

Posted Feb 27, 2008 20:28 UTC (Wed) by drag (guest, #31333) [Link] 

Yes.

The FLOSS world is full of interdependencies. Gnome depends on improvements in X for newer
features. Fedora/Ubuntu depend on improvements to Gnome and to X for their new releases.

Application developers depend on Gnome and X and other libs to be improved for their
improvements. 

Everybody depends on Users who actually need binary releases from distributions.

That is, to say, that if X does not pay attention to the needs of Distros they also ignore the
needs of end users and application developers. If there are no releases done with distros are
released, then there is really no point to even having a release. Nobody can use it, nobody
will use it. 

If you do feature-releases then your timeline is going to fluctuate. Users/Application
developers/distros can not depend on you to ship a product so they can't take advantage of
improvements you offer.  Delays build up, users get irritated, developers get bored, important
improvements and bug fixes remain unavailable to most users, and development stagnates.

Coordination is key. A convoy at sea is only as fast as it's slowest ship.

Fedora is important in this regard because they are the early adopters. They get things first
and flush out problems for other distributions. Ubuntu also follows the same pattern of Fedora
with 6-8 month release times so they are helped also by these timed releases. More users mean
more testing, bugs get found quicker and ultimately they get fixed quicker.  etc etc.

Time-based release actually works well

Posted Feb 28, 2008 11:49 UTC (Thu) by pointwood (guest, #2814) [Link] (1 responses) 

KDE is using a time based release schedule as well now:
http://tuxenclave.wordpress.com/2008/02/02/kde-41-roadmap...

Time-based release actually works well

Posted Feb 28, 2008 20:59 UTC (Thu) by Sho (guest, #8956) [Link] 

KDE point releases within a major release series (e.g. 3.x) have actually always been
date-driven. 4.0 didn't have a date for much of the release cycle because it was a
generational jump and greater flexibility was required in the face of the task.

Time-based release actually works well

Posted Mar 1, 2008 23:05 UTC (Sat) by sbergman27 (guest, #10767) [Link] 

"""
It's not necessarily a bad idea. Indeed, changing your schedule so that it meets your
customers' is a good idea, and most people use X.org from a distro - not directly.
"""

I find the increasing popularity of time-based releases to be refreshing and encouraging...
after years of hearing the phrase "it's ready when it's ready"  used to cover for a lack of a
proper release plan by some projects.

Deadlines mean that people have to buckle down and do the unfun stuff rather than perpetually
working on cool new stuff that's never quite ready for release.

The Xorg 7.4 release plan

Posted Feb 28, 2008 18:12 UTC (Thu) by nim-nim (subscriber, #34454) [Link] 

I'll take a release synchronized with a major distro over a free-for-all one every day.
Synchronizing with a major distro schedule means your new code is actually tested by a large
pool of users (distro testers) and bugs are actually reported and tracked (by the distro
maintainers that want to ship a solid release). There is no possible comparison with a release
that has only been tested by people who can and bother building vcs snapshots.

For example hal auto input code landed in Fedora devel last week (among much grief) but that
also means this code is going to be beaten into shape now instead of festering in an
almost-working state as it has for the last months.

(Fedora is good that ways, it enables the features everyone is afraid of and gets their
upstream to stabilize them instead of waiting for others to take the first step).

IIRC Linus publicly singled out the kernel versions that were released in sync with a Fedora
version as being more stable than the average ones, thanks in no little part to the Fedora
stabilization drive.

Bugginess

Posted Feb 27, 2008 19:53 UTC (Wed) by ncm (guest, #165) [Link] (3 responses) 

I've been running current Xorg, and it started getting crashy some time in December or early
January.  This was on an Intel i945G, and may have involved some interaction with Firefox and
animated gifs.  I finally switched to a PCIX card and the nv driver.  However, occasionally it
still stops processing any input from /dev/input/event2 (the mouse), even though separate
programs are able to read events from there.  Nv is also prone to 100% cpu usage for long
periods, something I have not seen in the 2007-09-22 version on my laptop.

Anyway, it's good to see a renewed emphasis on quality.

Bugginess

Posted Feb 28, 2008 1:59 UTC (Thu) by ringerc (subscriber, #3071) [Link] (2 responses) 

Do you mean PCI-E ? PCI-X is generally only used for big, expensive server RAID cards.

Bugginess

Posted Feb 28, 2008 6:31 UTC (Thu) by ncm (guest, #165) [Link] 

Probably.

Bugginess

Posted Feb 28, 2008 7:11 UTC (Thu) by ncm (guest, #165) [Link] 

To be more precise,  it's an NV44 (6200 rev a1) ASUSTek Unknown device 81d5 w/ 288M RAM,
2.6GT/s, Width x16.  But the X server does its 100% cpu usage even when nothing is rendering;
firefox is just doing its page layout, so I don't know how or why X is involved at all.

favorite burger topping

Posted Feb 28, 2008 14:12 UTC (Thu) by mgalgoci (guest, #24168) [Link] 

I'm a fan of lettuce, tomato, and onion, with a dab of ketchup and mustard.

Mmmmmmm.


Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds