[Release-wranglers] Re: Teleconference contact information for open source testing.

[Keith Packard]

--==_Exmh_1532611254P
Content-Type: text/plain; charset=us-ascii


Around 15 o'clock on Feb 25, "Kendall Bennett" wrote:

> I missed this mornings call due to other committements. Any progress to 
> report? 

Yes, I think Egbert and Kevin made a pretty persuasive case for producing 
a release as close to XFree86 4.4 RC2 as possible; they're both on very 
tight schedules and were planning on moving to 4.4.  A release which 
differs from that in any substantial way will force them to fall back to 
either 4.3 or home-spun 4.4-ish bits.  Neither of those positions would 
help anyone in the long run.

I think the proposal is then to take XFree86 4.4 RC2, figure out what 
patches have been applied in XFree86 CVS since then, discover what legal 
obligations we have to respect the XFree86 trademarks and ship the result.

Changes to Xlib UTF-8 support, Xinerama and X server internals will have 
to wait until after that release; otherwise we're going to miss two very 
important Linux release trains here.

Somewhat unresolved are issues over precisely what kind of releases we'd do 
after that are still on the table.  Let me recap my thoughts on the issue 
here.

--

+ Composite support in the X server changes the DIX/DDX interface and may 
  require recompiling video drivers.

+ Discarding the XFree86 loader and moving to dlopen will require 
  recompiling video drivers.

+ We should avoid breaking video driver interfaces twice.

+ We have a desire to (quickly) stabilize the driver interface so that video
  drivers can be released separately from the X server.

Ok, so given that we'll be shipping XFree86 4.4 RC2, that means no 
Composite extension and the XFree86 loader -- so, we can't finalize the 
ABI with this release.  However, we'd like to take advantage of the 
modular build environment to release new drivers for the monolithic server 
at some point.

I'd like to avoid two modular X builds, one of which is backward 
compatible with the monolithic environment and one of which is forward 
compatible with future modular releases.  That seems like a really good 
way to confuse people.  That's not to say that the modular tree should 
never be backward compatible.  

To allow people to avoid duplicating a bunch of driver development and
maintanence, I suspect we'll want to make the modular drivers target both
the monolithic and modular servers for a while at least.  Whether this is 
done by creating an imake-based DDK for the monolithic environment, or 
making sure that we can use autotools somehow.

-keith



--==_Exmh_1532611254P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.3.1 11/28/2001

iD8DBQFAPTp+Qp8BWwlsTdMRAunRAKCl3Q70udN3oV5Mar0QrKV+mUd9jgCeORWK
1X8970/GMNyiiaVEWB8fjeo=
=NmrH
-----END PGP SIGNATURE-----

--==_Exmh_1532611254P--