(Sorry for the lack of context -- I joined just after this mail got
sent)

To introduce myself, I'm (so far) essentially FreeBSD's x11 team, a DRI
developer, and a current committer for X.Org and various X-related
freedesktop projects.  I've been working on moving FreeBSD to X.Org,
which means that FreeBSD-current is now using the xorg ports, and I'm
hoping to move FreeBSD-stable over too, once I can figure out a clean
upgrade path for them (changing package origins can be messy).

To fill you in on X.Org's plans:

X.Org is planning on making a second release at the end of August.  That
means a feature freeze this Friday and code freeze mid-August.  We'd
like to see this release remain as portable as possible, but there may
be breakages due to lack of test coverage -- the current developers
don't have the capacity to install and test on all the OSes we should
support, so things may have unknowingly become broken.

We'd love to see some NetBSD folks get involved.  I've been keeping
FreeBSD support going well, and Matthieu Herrb has been working on
OpenBSD (and general *BSD) support.  Active NetBSD maintainers might
also be able to help improve our portability to other architectures
besides the x86, amd64, and sparc64 that most of our current developers
are using.

You can see what we're planning on for the August release here:
http://freedesktop.org/XOrg/XorgReleasePlan
and the sign-up for testing here:
http://freedesktop.org/XOrg/XorgReleaseStatus

For things that I'm sure will be included from Proposed Features,
there's Composite, Damage, and XFixes, which radically change how your
desktop can work
(see http://xserver.freedesktop.org/Software/TranslucentWindows for info
on the shiniest new feature allowed, but not the only one).
I'm pretty sure the trapezoid changes are going in as well, which is
important for cairo support.  Cairois the rendering API that is heading
toward widespread adoption (Mono is using it, GTK+ is moving to it, but
I don't recall whether Qt people have plans).

For the next release after that, there are several projects in the
works, though this list is certainly not complete:

One is XCB (http://xcb.freedesktop.org/) which is a library that
provides essentially just a binding of the X Protocol in C, rather than
the monstrous API of Xlib.  This allows for significant reductions in
the round-trips that help make remote X so painful, along with a small
binary size appropriate for embedded platforms.  XCL is an
implementation of Xlib on top of that, so you can use XCB and Xlib APIs
interchangably, providing a migration path.

Another is the autotools modularization.   The libraries and headers
have been broken into separate packages.  The server is being
modularized in a project called "debrix." This includes efforts to make
the server use the ELF loader instead of XFree86 .a loader, which is
likely to improve portability to other architectures (or so I'm told)
along with finally making debugging really possible again.  The
autotooled server distribution will also allow people to compile single
drivers without having to compile a whole tree.

Finally, my main project for the next release after this is to replace
the aging XAA (XFree86 Acceleration Architecture) with KAA, which is
smaller, simpler to write drivers for, and better suited for
acceleration that's needed in current X desktops.

---

To put away one of the concerns many have had, we are doing everything
possible to avoid any breakage of backwards compatibility in X.Org.  One
case of (somewhat small) breakage, however, was the Xinerama 2.0
update.  This maintained the old API and ABI in the library while adding
the new 2.0 API, but didn't keep support for the 1.0 protocol in the
server.  This means that your old apps continue to work, but if run
against the X.Org server they won't be able to use Xinerama features. 
The other source of concern right now is that Composite may have adverse
effects on the specific case of background=None windows in the presence
of a compositing manager.  This one should be dealt with, I think, by
the time of release.

The upshot is that you can drop X.Org in, and things will Just Work,
with no recompiling of all your client apps.

---

So, as far as NetBSD goes, I'd love to see some active maintainers to
push whatever changes NetBSD would have for X.Org upstream.  We've got a
bugzilla (http://bugs.freedesktop.org/), and CVS access is pretty open
to anyone who's had a good track record of patches and seems committed
to working on the tree.  Many of the XFree86 developers are also working
on X.Org, even if they're also pushing their fixes into XFree86 as well,
and many of us don't have XFree86 CVS access.  Because of this, I
believe that X.Org is really the future of X development.

One thing that could help keep us sane on NetBSD would be to set up a
tinderclient for X.Org for whatever architectures you could.  We've got
information on the tinderbox scripts at
<http://www.freedesktop.org/Software/TinderboxWiki>.  I'll warn you in
advance, though, that our current scripts are a little rough around the
edges, and as you can see at http://tinderbox.freedesktop.org/ we've got
a current build failure on systems with Freetype below 2.1.8 where the X
build defaults to using the system Freetype.

Sorry for the rambling nature of this.  I'd love to answer whatever
questions I can, and I'm subscribed to the list now.

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