X.Org Modularisation
'Where to from here?'
Daniel Stone <daniel@fooishbar.org>
freedesktop.org
Table of Contents
- Modularisation: what? why?
- Current status
- Where we need to be
- How we should get there
- Original timeline
- Proposed new timeline
- Online resources
- How to help
- Conclusions
Modularisation: what?
- Separating 330MB of source code into smaller chunks
- Major components: protocol headers, libraries, server, drivers, apps, docs,
fonts
- Using standard autotools-based bulid system instead of imake
Modularisation: why?
- Smaller, individual pieces of code easier to manage
- Don't need to rebuild everything every time
- Easier to push out releases of smaller modules for testing
- More universally understood build system
Current status: protocol headers
- Foundation of the X Window System
- Used by server and libraries alike
- Only need to copy the header files around -- this is easy
Current status: libraries
- Most fully autotooled
- Main libraries generally working (libX11, libXt, et al)
- Others should be completed this week
- Some minor breakages in some libraries
- Configuration options not all present
Current status: server
- Debrix (proof-of-concept) built a working loadable server last year
- Most still directly applicable to current sources
- Basic server autotooled and roughly working
- This talk is running on a modular server
- Most build options not configurable as they should be
- Some subsystems not yet completed
- Completion target: July 1st
Current status: applications
daniels@catsby(modularx):~/x/xorg/app% ls
CVS twm xdpyinfo
- Only two apps autotooled to date, more in xapps repository
- Very straightforward to complete
- Require libraries to be completed first
- Should be a very good litmus test for the libraries, along with VSW5
Current status: drivers
- ATI and Intel drivers autotooled
- This process should be quite simple
- Many autotooled drivers can have infrastructure borrowed from Debrix
Where we need to be
- All libraries we plan to keep on supporting should be buildable with basic
options, and usable
- Server should build and be flexible enough to work on most popular OSes
- Few, if any, regressions in supported driver set
- Applications we're interested in keeping should be autotooled,
externally-maintained ones farmed out
Driver set: conversely, if we're going to break it, why not do it now? R7
provides golden opportunity.
Ditto libraries. Deprecation like DPS should be considered if there's something
that's not being used that we really don't want to support.
Original timeline
- May 13th: protocol headers
- May 27th: libraries
- June 10: server
- June 24: apps
- Missed dates for libraries and server due to slow starting
- Release in two months probably impractical if we want stable and well-tested
August 19th isn't going to happen.
Proposed X11R7 timeline
- Feature freeze: new features to be done on a branch
- RC1: 1st July -- working libraries, basic server
- RC2: mid-July -- more drivers autotooled, server ported to more platforms, most
applications completed
- RC3: early August -- all features solidified, most final-release ports
complete, docs and release notes begun
- (cont)
Proposed X11R7 timeline (cont)
- RC4: mid-August -- additional port work and bugfixes, most configurable
features complete
- RC5: early September -- code freeze, only bugfix updates until final release
- Release: mid-September
Proposed X11R7.1 timeline
- Feature freeze: +3 months, new features on a branch
- RC1: +4 months -- code starting to stabilise
- RC2: +4.5 months -- decisions made on what to release with; unstable
subsystems disabled by default or removed, docs to be prepared
- RC3: +5 months -- code freeze, bugfixes only
- RC4: +5.5 months -- critical bugfixes and doc updates only
- Release: +6 months -- 7.1 released
Proposed X11R7.2 timeline
- ...
- Release: +6 months, 7.2 released
Online resources
- Mailing list: xorg-modular@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-modular/
- IRC: #freedesktop, #xorg-devel
- Modularisation working group main page:
http://wiki.x.org/wiki/ModularizationWorkingGroup
How you can help
- Check your particular subsystem/driver works fine. If not, see what can be
done to fix it
- Test regular X applications against the built libraries and server to see
if it all works
- Test various combinations of builds to see whether our dependencies are
correct
- Report bugs against anything that's broken
Conclusions
- Development needs to be initiated by a core team -- others will
usually only get involved if there's a base to work from
- Probably cannot be carried off with such a small team with other
commitments
- Get involved if you want to see R7 hit its schedule!
Questions
Thankyou
- Email: daniel@fooishbar.org
- Slides: http://people.freedesktop.org/~daniels/exdctalk/