[Xorg] Notes from release call

[Eric Anholt]

Here are a few notes I'm writing down from the release call, in case we
don't get minutes.  I wasn't paying attention to who said what, so these
are just my impressions/conclusions from the call and are not complete
in any way.

First topic was .so modules:
- keithp explained the debrix work on making the server use .so
modules.  We should be able to produce .so modules that retain
cross-platform compatibility for anything using ELF by using the libc
wrapper, as long as the modules avoid certain hazardous functions
(setjmp/longjmp)
- debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
on autotooling the x server but have found sticky issues with modules
involving references to global symbols.  They've been fixed in that
tree, mostly, but this may prove to be a hazard for vendors moving to
.so modules
- We should make our modules as .so, which gives us more architecture
support and debugging ability, but retain the old loader if it proves
difficult to make the switch fully.  We could also take vendors' .a
modules they produce and convert them to .so using ld probably.
- Has anyone tested .so modules cross-platform?  Nobody on the call at
least.  anholt was volunteered for testing.

Modularizing the build:
- keithp had volunteered, eich had volunteered to help, but progress has
stalled due to lack of time.
- keithp doesn't have time until at least 3 weeks from now
- Many, but by no means all libraries have been autotooled in the xlibs
project, so we have a basis to work from
- Modularizing of xorg can be done incrementally.  First, rearrange
includes directory to make modular while retaining imake build, which
allows the libs to be done.  Later the xserver autotooling can be
brought in, at which point the imake build can be left to rot.

Composite:
- anholt has attempted to do Composite support for XAA, which was never
completed, but the first thing to do would be to make a wrapper at the
miext layer that retained binary compatibility.
- If we move the new fields in PixmapRec to the end, we shouldn't have
any binary compat issues, because nobody should be statically allocating
PixmapRecs (since they wouldn't have the privates), or at least if they
do, the rest of the server shouldn't be seeing them.
- anholt concerned about doing Composite wrapper because of lack of
experience, eich suggested he could.  (I'm attempting it anyway)

Release:
- Timing of next release: two months?  end of year?  next year?
- Proposed that we release in time for Fedora Core 3
- FC3 schedule would require a release by Sep 6?
- Proposed that we target having a release by Aug 25
- General agreement found.
- What should be in release?  Composite/Damage/Fixes found general
agreement.  What else?  Call put out to xorg@

-- 
Eric Anholt                                eta at lclark.edu          
http://people.freebsd.org/~anholt/         anholt at FreeBSD.org