Xorg 7.4 release plan

Tue Feb 26 12:32:05 PST 2008

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.
>
> 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.
  Until all drivers are either ported, or dropped, at least an interface
that converts old functions calls to pciaccess format should be made.
  Last time I looked at the code, there was initial work on it, and since
drivers that have support call xf86AddDriver with "HasDriverFuncs" argument,
instead of 0, it should be possible to adapt at run time.
  I am concerned more about if also because I need to work with VIA
and SIS hardware and binary only modules for OEMs; and long delay from
the vendors to adapt to changes.

> 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.
  I did not do much testing with input hotplug (lack of hardware/time).
I believe Daniel and Peter are working hard on it, but I still don't feel
confident to enable again hal/dbus suport, as Mandriva is also close to a
newer release.
  For the mice axis, probably making sure SendCoreEvents and AlwaysCore
options don't exist in xorg.conf should be enough. Mandriva is using
origin/server-1.4-branch plus some "cherry-picks" and xkb seems stable.
> 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.

  Ideally, git master should be always in an stable state, but 
unfortunatelly
it is not, so  I suggest using server-1.4-branch for the X Server, otherwise
the breakage may be too much to handle, and this is what most distros are
already using.

> Questions?  Comments?  Favorite burger topping?
>
> - ajax
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

Paulo