RE: A Call For Open Governance Of X Development

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Havoc Pennington
> Sent: Friday, March 21, 2003 4:50 PM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [forum] A Call For Open Governance Of X Development
> 

...

> Take a concrete problem: we have this huge stack of ICCCM
> extensions/clarifications. Should those be merged into the ICCCM or in
> some way "blessed"? Who would do that and how?
> 

THIS, IMHO, is one of the key issues to be resolved in the X community, and
one I raised in my diatribe. Specifically, this is the "governance of X"
issue. I'm gonna use ICCCM as an example, because Havoc used it, to try to
clarify what I'm talking about w.r.t. "governance", but these issues apply
to most everything in the specification of X (as opposed to the
implementation of X).

ICCCM is a standard owned and managed by X.Org. Formally changing ICCCM
isn't the same thing as creating something new like Render, which is a
disjoint extension. Strictly speaking, changes to ICCCM need to get funneled
to X.Org.

XFree86 is represented in X.Org, so a valid argument could be made that
XFree86 should be sponsoring these changes back into X.Org. I accept that. A
few sub-issues to explore:

(a) What would be the channel to get ICCCM-proposed-changes from the desktop
environment projects to XFree86 for sponsorship?
	(a1) One avenue is to have XFree86 reps who are participating on
these projects bring them back to the X.Org rep on the Core Team. In the
world we thought we lived in, where Keith was supposedly representing
XFree86 with these projects, as an XFree86 Core Team member, Keith should
have brought these issues to the Core Team, or directly to David (currently
our rep at X.Org), for sponsorship.
	(a2) Someone (e.g. Havoc) from the desktop projects could have
brought these issues to XFree86, via devel, or to the Core Team, or directly
to David.
	(a3) Some sort of conduit should be created so that the desktop
projects can represent themselves in X.Org, and the experts can deal with
the issues directly with appropriate other X.Org representatives.

(b) Wouldn't be better if domain experts, like the desktop projects, were
directly represented in X.Org to deal with this? This is a problem, because,
like the old X Consortium, X.Org has no concept of individual membership,
and the lowest level of membership cost $3000/year. XFree86 is an "honorary
member", a position that doesn't officially exist, mostly because we said
"stuff it" to $3000/year, and X.Org felt they needed XFree86 for
credibility, so they created this position (or something to that effect; I'd
have to go dig up what actually happened).

(c) What should be the development/standardization process once the
appropriate representation is in place? Are the desktop projects willing to
deal with dissenting views in X.Org? Does development wait for
standardization? Etc, etc.

Now, for better or for worse, as far as I can tell, the XFree86 Core Team
thought we were in the (a1) state. Right or wrong, that's where we thought
we were, and hence were not aware. I think (b) is the right place to be, but
X.Org makes it difficult to impossible

Another avenue is say "to hell with X.Org, we'll do our own version of
ICCCM". To some extent, this is what has happened, right? Probably de-facto.
So who should take ownership of formalizing this? Should it be XFree86? The
desktop projects? LSB? I'm really not sure. Historically, it has NOT been
XFree86, but perhaps there is a perception that it has been, or a belief
that it should be.

Yet another avenue would be to say "ICCCM is what it is, we're going to
define something new, called ICCCM++, which is a superset of ICCCM
v<whatever is the current standard>, but we'll go do our own thing, and
ICCCM can go do its own thing, and maybe we'll sync up later". This would be
more analogous to the server extension model, I think, and (to my mind) is
more in keeping with how much of the Open Source world does things (e.g.
GNU-specific extensions to POSIX.2).

There is a LOT of work to do in this area. By a LOT of teams, not just
XFree86. X.Org needs to play (and I believe that they are working on this).
LSB needs to play. The desktop projects need to play. The vendors need to
play. And fixing this is the good that can come from the bad way Keith has
handled this situation.

Note that these issues are independent of issues of how XFree86 is run, how
many people commit code, branching, whatever. If we wind up either fixing or
replacing XFree86, and don't address these sorts of issues, Havoc is STILL
going to be asking "and what do we do about ICCCM".

> Havoc

-- 
David Wexelblat, Chief Architect    mailto:[email protected]
America Online, Inc                 http://www.aol.com/
44900 Prentice Drive - 24B:P08      (703) 265-1158 (voice)
Dulles, VA 20166                    (703) 265-1301 (fax)
	
Please send private email to: mailto:[email protected]