Disable xterm and XRX builds per default / [Fwd: CVS Update: xc (branch: trunk)]

[Daniel Stone]

On Mon, Jan 24, 2005 at 11:52:34AM +0100, Egbert Eich wrote:
> Roland Mainz writes:
>  > Daniel Stone wrote:
>  > > Who owns xterm?  Thomas Dickey?
>  > > What about FreeType?  The FreeType project, I dare say.
>  > 
>  > Who decides such changes ? AFAIK the Xorg arch board or the Xorg
>  > directory are allowed to make such a drastic change or approve it unless
>  > it goes through a bug.
> 
> The usual way to do it would be to say "we don't know if anybody still uses
> it, some people believe it should be deprecated therefore lets disable it
> and see who complains" - that's been the procedure with PEX and XIE.
> In the vast majority of cases there is no need to go thru any board.
> 
> Here we have people who complain - therefore it would be rude to subbornly
> insist on the decision.

Ah yes, but surely it would also be rude to insist on the decision otherwise, if
there are also people with a contrary point of view. :)

> Here I agree with Roland that going thru a bugzilla entry would be have 
> been an appropriate step.
> Since Daniel expects cooperations by others - he requested me not to 
> commit pieces of code that don't have any relationship to each other 
> together - he should also be cooperative.

I didn't think that the multiple-change thing was as debatable as this, but if
you would like to keep commiting many pieces of unrelated code altogether, feel
free to do so: I won't stop you or mention it further.

>  > BTW: I am the XRX maintainer and I doubt all the non-Debian platforms
>  > are that happy that you disabled xterm in the default build.
> 
> Since there are still consumers of the xrx technology it would be
> inappropriate to disable it.

It is not disabled -- people who want XRX can follow a deadly simple procedure
to get it.  Namely, echo '#define BuildPlugin YES' > config/cf/host.def.  Unlike
most parts of the tree, I can't imagine the case where someone would just
discover XRX and decide that it might be cool to use.  It seems to be very much
of a case where people who want to use it, know they want to use it.  And they
can type a one-line command, surely.

> xterm is maintained somewhere else so I understand the decision.

Right, which is why, if we insist on this insane monolithic structure, it should
at least be in extras/.  Otherwise there's no point to extras/.

> However I think it came at the wrong time.
> Furthermore I don't believe that this step would be any more as
> we are expected to go modular soon anyway. 

Not really; apparently a few people on this list think we should never, ever go
modular[0], so I don't think we can claim consensus any more there than on, say,
disabling FreeType builds by default.

>  > > In fact, as a distributor, I would say I have more right to config/cf/* than you
>  > > do, but there you go.
> 
> How come?

The joys of having your private mail sent to a mailing list, eh?

> Other distributors either add their custom configuration to linux.cf
> or supply it their custom configuration in a host.def file.

FWIW, I do the former.

> I personally would prefer to have a per-distributor configuration 
> file which can easily be included when a certain distro is detected.

Sure, we have sections for this in linux.cf today.  But I think the entire
concept of having this in the upstream tree is a bad one; much as I have avoided
merging the debian/ tree for D-BUS upstream, likewise would I rather see all
distro-specific configuration out of the upstream X.Org tree, since it doesn't
belong there IMO.  Ho hum.

Cheers,
Daniel

[0]:
http://lists.freedesktop.org/archives/release-wranglers/2004-May/000623.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20050125/3281cb68/attachment.pgp>