Re: A strawman proposal for X.org & XFree86.org

Vadim Plessky wrote:
> While many points in this proposal are valid, there are some *untouched* 
> questions:
> 
> 1) wether Sun and other X.org members take *as commitment* duty to develop 
> support (or backport existing code from XFree86 CVS) for existing and 
> upcoming XFRee86 extensions, like RENDER, Xr, Xc?

Each individual member will support or not support the XFree86 extensions as
their business needs see fit.  This is the situation with every X vendor,
including those who already ship off the XFree86 code base, and the way it
should be.  Several vendors, including Sun & XiG (who is not an X.org member),
have chosen already to port RENDER to their non-XFree86-based X servers,
presumably because they determined there was sufficient customer demand for
RENDER at this point.  If Xr & Xc similarly prove themselves, vendors will
again have to decide whether the cost of adding support is more or less than
the cost of losing customers who demand the support.  X.org is not requiring
every X or XFree86 vendor to ship & support every single extension in the
X.org codebase - would you think it fair to require everyone to commit to
supporting XIE, PEX, and Xprint?

> Without such commitment from X.org members *in written*, with timetable to 
> complete the port specified, further discussions about merging X.org and 
> XFree86.org make no sense, IMHO.

Why should you dictate how the vendors choose to spend their resources?  The
discussion here is about how best to manage the two open source implementations,
the X.org sample implementation & XFree86, which is a superset of the X.org.
What the vendors choose to do with the results is their business.  You have no
written commitment with timetable from Redhat, SUSE, FreeBSD, or anyone else to
support Xr & Xc, so why should Sun, IBM, HP, etc. be any different?

> 2) there is nothing said about trimming X codebase, and in particular - 
> eliminating support for PCF and BDF fonts in favour of Freetype backend and 
> TTF fonts with embedded bitmaps.
> Many open-source developers are concerned with XFree86 codebase size, and they 
> expect trimming fat from codebase (and not merging with X11R6.7)

XFree86 already contains all of X11R6.6 - there's not a ton of new fat in 
X11R6.7 that's going to bloat XFree86.  In any case, those concerns are outside
the scope of this proposal - the proposal is about determining how technical
decisions and changes to the code will be made, not about predetermining the
results of those decisions.

(I am a bit confused though - if you are so worried about reducing the size
of X, why are you also so insistent on increasing it with Xr, Xc, etc.?)

> 3) my experience of talking to engineers/sales&marketing people in couple of 
> "leading UNIX vendors" shows that people from those companies are very proud 
> with their "in-house" UNIX implementations, and mostly consider open-source 
> software as a joke.
 > Therefor, I doubt that X.org memebers would accept your proposal .

I'm fairly sure every single one of those Unix vendors that ships an X server
is based on the X.org open source implementation already.  The X.org members
have been giving money for years to support further development of the X.org
implmentation as open source.  I don't think you'll find the resistance you
expect.  (I know the leading UNIX vendor I work for is heavily involved in
many open source projects, and does not consider it a joke.)

-- 
	-Alan Coopersmith-      [email protected]
	 Sun Microsystems, Inc.   -   Sun Software Group
	 Quality, Integration, & Customer Success (QICS)
	 Platform Globalization Engin. - X11 Engineering