xc/programs considered harmful

Roland Mainz roland.mainz at nrubsig.org
Fri Dec 17 09:14:59 PST 2004


Daniel Stone wrote:
> > Daniel Stone wrote:
> > > 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.
> 
> Can we please move it to extras/, to reflect the fact that pretty much
> all we do is import from its upstream, Thomas Dickey?

Noone except you complained about that detail yet... why is that move
needed ? It just causes (unneccesary!) work...

> > > xc/programs/xlogo
> >
> > Sure, a xlogo is demo application but sometimes being used by twm users
> > do have a background. And I doubt anyone will approve the removal of all
> > the demo applications just because they are not being actively being
> > maintained. If you really think these applications should be removed
> > please file a message to the Xorg arch list - they are the people which
> > approve new applications in the tree and therefore I assume a consense
> > there is needed to remove applications, too.
> 
> I would be happy to formally propose the move of these to the modular
> tree.

AFAIK the plans for modularisation have the label X11R7.x - why the
hurry now ?

> > > xc/programs/xclock
> > > xc/programs/xeyes
> >
> > Both are being used by twm users, too (you don't want to rip-off twm,
> > too - right ? =:) ...
> 
> No, absolutely not.  But I don't see the need for these small client
> applications in the monolithic tree, any more than we need a web browser
> in xc/programs.

I _do_ see a need for sample application in the tree. EACH single X
extension should have a demo application in the Xorg monolithic tree -
for example "xeyes" shows the functionality of the SHAPE extension,
"xclock" contains demos for RENDER and XST etc. ...

> > > xc/programs/xbiff
> > > xc/programs/xcalc
> > > xc/programs/xedit
> >
> > xedit is actively being used, too.
> 
> So let's move it to the modular tree.

Please no. Why is this effort needed _now_ ? Could you please explain
why you are suddenly are in such a hurry to get rid of every application
you don't care about ? AFAIK the plans for a modular tree are
implemented soon enougth (e.g. X11R7.x). I do not see any urgend demand
to cause chaos and trouble...
 
> > > xc/programs/xmessage
> > > xc/programs/xmh
> > > xc/programs/xman
> >
> > xman is actively being used, too.
> 
> So let's move it to the modular tree.

Again: NO.

> > > xc/programs/xrx
> >
> > xrx&co. is part of the X/Broadway technology which is actively being
> > used in intranets (and it's even being maintained - if you take a look
> > into trunk you'll see a bunch of fixes for it...) ...
> 
> So let's move it to a tree of its own.

Huh ? Why ? X/Broadway is part of the set of X11 technogies and belongs
into the tree. If it really needs to be moved then to the "xapps"
repository (which itself is sightly problematic as X/Broadway also comes
with two plugins for web browsers).

> > > xc/programs/xvidtune
> > >
> > > 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.
> 
> No, it is not to cause problems for anyone.

Can you prove that ?

> These are all small (and
> most of them rather infrequently-used and/or infrequently-maintained)
> client applications, and I believe these are absolutely out of the scope
> of X.Org -- just as we should not be including a web browser.
> 
> It is not to cause trouble to anyone.  If we are to move to the modular
> tree, we can't just expect it to sort of happen the week before the
> release or something.  The work needs to start (no -- we have working
> client-side libraries and a server; let's say 'continue') now.

This work should _not_ affect the Xorg monolithic tree at all. The
transition to a modular tree should be smooth and people should be able
to have a choice between all-in-one-monolithic and the modular trees for
now. And therefore draining the Xorg monolithic tree from any sample
application is a NO-GO for the X11R6.x release series.

> If you
> wish to keep the monolithic structure and not transition to a modular
> tree, please let me know and we can have that debate.  But I think there
> is universal consensus on where we need to go (modular), and how to get
> there (gradually transition applications out of the monolithic tree).
> 
> Users of these applications would not suffer any magical quality drop or
> such.

What about: Distributors will have to invest significant amount of
manpower to get the new build system in xapps working in their trees.
And there will likely be a quality drop in the first one or two cycles
due regressions and other problems with the new build system (based on
the fact that the "xapps" tree is horribly out of date and doesn't even
build on non-Linux platforms (like Solaris) makes me think that noone
uses the "xapps" repository right now) ...

> > > They have no place in the tree as we move towards a
> > > monolithic structure, and at least one (xterm) has a very active
> > > upstream.  If xterm remains in the monolithic tree, it should be moved
> > > to extras/,
> >
> > It may be better think about doing the xterm development in the Xorg
> > CVS.
> 
> Please, no.

Why ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)



More information about the xorg mailing list