Differences between revisions 46 and 47
Revision 46 as of 2010-11-02 21:35:58
Size: 4127
Editor: ?JulienCristau
Comment: update
Revision 47 as of 2010-11-08 15:25:33
Size: 4396
Editor: ?Ananth
Comment: Removed broken link to Ender's page
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
  * [[http://ftp.es.debian.org/~ender/XSF_bugs/|Bug graphs per package and total]]
  * [[http://udd.debian.org/bugs.cgi?release=sid&patch=ign&pending=ign&security=ign&wontfix=ign&upstream=ign&forwarded=ign&claimed=ign&deferred=ign&notmain=&notsqueeze=&base=&standard=&merged=ign&done=ign&outdatedsqueeze=&outdatedsid=&needmig=&newerubuntu=&fnewer=&fnewerval=7&xsf=1&sortby=last_modified&sorto=asc&cseverity=1&ctags=1| Bug search @ UDD]]

The Debian X Strike Force TODO List

  • build the few missing drivers against 1.9 in experimental
  • Investigate what apps should be dropped
    • xsetpointer
    • xsetmode?
    • xedit?
    • ...
  • Deal with any new classes of bugs documented in ?XStrikeForce/CurrentProblemsInUnstable

  • Clean out the BTS so that it's useable for mortals (endless task)
  • Improve the autodetection code, running with a partial xorg.conf should share more code with the 'no config file' case
  • Kill xsfbs
    • The most critical part of xsfbs for us is the patching infrastructure. Using quilt was the right decision, but we're carrying around our own version of the patch system when it should be the quilt package handling this. The package does come with a Makefile that we can source, but we need to add whatever extra bits are necessary for us, and dump this infrastructure.
      • The patch-audit code needs to be adapted and pushed to the quilt package
    • The shelllib (xsfbs.sh) is full of useful functions, but why are we carrying them around if they're generically useful? We need to put them in a generic place, much like make-orig-tar-gz and prune-upstream-tree above, so we don't have to carry them around. Possibly also debhelper programs.
  • Ship missing drivers?
    • xserver-xorg-video-ast
    • xserver-xorg-video-impact
    • xserver-xorg-video-vermilion
    • xserver-xorg-video-wsfb
    • xserver-xorg-video-xgi
  • Rename libxss into libxscrnsaver(?)
  • Investigate moving update-fonts-* to triggers, and moving the fonts.{scale,alias} files outside of /etc

Other Ideas

  • Document more XTips and clean up the XStrikeForce/FAQ (and ship it again, #408293)

  • Provide more scripts to make the lives of the XSF members easier. Pool these somewhere (currently there's a few junky ones at http://people.debian.org/~dnusinow/xsf_scripts/)

  • Debian BulletProofX : Failsafe mode that will be used if X fails to start up. It will be in a reduced (VESA 800x600/256 or VGA 640x480/16) graphics environment running a single application (displayconfig-gtk) for configuring the graphics devices. The goal of this proposed specification is to eliminate the need for users to need to run apt-get reconfigure on the commandline. That approach is confusing and too technical for many users, so moving away from that will solve a key pain point for users.( see https://wiki.ubuntu.com/BulletProofX ). While this is an important goal that we've been aware of for several years (indeed, many of the TODO items have been geared towards achieving this) the current design is suboptimal for several reasons, and should not be accepted in to Debian in its current form. Issues keeping it out of Debian are:

    • It relies on a *dm to be able to work at all, leaving anyone using startx or a *dm that doesn't explicitly support it out in the cold. Witness Kubuntu users grumbling about this feature.
    • The maintenance burden is entirely on the distro maintainers for this feature currently, rather than our upstreams. Notably, distros like Redhat/Fedora are equally resistant to BulletProofX, pretty well guaranteeing that we'd have to maintain it ourselves. This goes against most of the work done these past two release cycles, including everything on this TODO list. Instead we need to work towards a cross-distro solution in conjunction with upstream.
    • There is no good reason why this can not be done better in the server itself, which would open up several possibilities for finer grained improvments that take advantage of the server's knowledge.
    • The specification mentions ignoring a user's xorg.conf all together, and instead requiring the user to re-enter everything using displayconfig-gtk (which is not currently a general xorg.conf manipulator) when they already have specified perfectly good information. Putting this functionality in the X server prevents this need.