xc/programs considered harmful

Kristian Høgsberg krh at bitplanet.net
Fri Dec 17 09:34:38 PST 2004


Roland Mainz wrote:
> Daniel Stone wrote:
> 
>>Hi all,
>>Does anyone realistically care about[0] the following directories:
>>xc/programs/xterm
> 
> xterm is being used and should stay exactly at that place. Even when the
> only reason is to avoid screwing-up the CVSblame.

Exactly what interesting cvs blame do we have in our xterm cvs history? 
The only work being done there is sync'ing with upstream which surely 
does not generate any useful cvs history.

[snip list of presumably actively used applications]

>>If no-one objects (read: steps in and starts maintaining the relevant
>>program) to the removal of any of these, I would like to kick them from
>>the tree ASAP
> 
> Daniel: Why is that neccesary ? The only "gain" here (beyond to push
> your pet project "modular tree") is to cause trouble for other people,
> nothing else.

Hey!  Could you *be* more patronizing?  This is not just Daniels pet 
project, there's a wide consensus that we need to break the tree into 
more maintainable components.

If I were maintaining, say xedit, I'd sure want to control my own 
release schedule rather than be tied to the schedule of the 50MB tarball 
or assorted random programs that is the current monolithic release.

And what are we doing, shipping an Xaw based, lisp enabled editor 
anyway?  If we want to do that, shouldn't we ship emacs instead?

> It may be better think about doing the xterm development in the Xorg
> CVS.

For what purpose?  What benefit does xterm users and Thomas Dickey get 
from tying the release of xterm to the entire X server?  Is it a cool 
feature that you have to download 50MB source to get the latest xterm 
security fix?  In fact, I think xterm is a perfect example of how well 
modularization could work.  What I see is that xterm has an active 
maintainer that cares about it, stays on top of security problems, and 
puts out new releases when it makes sense for xterm.

Kristian




More information about the xorg mailing list