xc/programs considered harmful

[Daniel Stone]

On Fri, 2004-12-17 at 18:14 +0100, Roland Mainz wrote:
> 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...

Yes, but we do not maintain it.  If we are going to keep dragging it in
from upstream, surely the monolithic archive should reflect this.

If xc/programs/xterm is a short-term hack, then say so.  But if it's
there to stay, then dude, let's do it properly.

> > 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 ?

If you ever want to release R7, then you need to start development on it
at some point.  If we sit around just growing the monolithic tree and
adding whatever sounds like a good idea, then we will never, ever have a
modular tree.

Ever.

Despite the efforts of the people who have already proven that modular
libraries and servers work, and created all the infrastructure so that
all that is left to be done is port the new code back to the current
infrastructure, because of the code drift.

If you want that to be done, let me know, and I'll disengage from the
X.Org structure and flow and continue working again.  But I don't want
to see that happen.

> > > > 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. ...

Why is this important?  If we want to create a test suite, why don't we
actually create a test suite?  (I think this is a very good idea, by the
way -- thankyou for the inspiration.)

Maybe we could use the stuff that's at TOG (IIRC) as a basis for this
work.

> > > 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...

Hm.  By your implication, I don't care about anything in the modular
tree.  Which was, last I heard, my 'pet project'.  I would call Debrix
my baby, since I spent quite a lot of time working on it, and had a lot
of fun along the way, and would love to see it still used.  And where is
it now?  Sitting in a modular structure.

I don't think these apps have any place in the canonical distribution of
X.  No more than a web browser.

Does moving it to the modular tree imply that maintainence quality will
instantly drop?  If so, obviously the maintainers don't care about it
anyway.

> > > 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).

By your logic, we should be subsuming most every X app, ever.

Why would having it as part of xapps be a problem, any more so than
having it around in xc/programs?  If its *existence* in xapps is a
problem, than its existence is a problem, full stop.  I'm afraid I don't
understand this paragraph.

> > > 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 ?

I'm not sure I can offer scientific proof that I am not a troublemaker,
who is just saying these things for fun.  No, not fun, actually --
malice.  Malice, yeah.

I cannot offer you absolute scientific proof that I'm acting out of
malice.  You have asserted that it is so because we disagree, which is
rather unfortunate (the former; there is nothing inherently wrong with
disagreement itself).  I would just say that's horrific argument style,
rather than anything.

If you want to call me malicious, then do so, and then I'll recommend
that X.Org removes me from access to anything it has as soon as
possible, or moves if that is not practical, if X.Org as a unit agrees.
But if you're not going to call me malicious, stop just implying it.

> > 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.

How can you ever move away from something without it being impacted?
Ever?

The transition proposed *IS* smooth.  Parts of the monolithic tree
gracefully migrate to the modular tree, without massive losses of
functionality, no sudden amazing huge bugs, or whatever.

By your logic, I can absolutely guarantee you that a transition will
never occur.  If you disagree, I'll tell you why.

Debrix.

By the time it was fully developed, so much code work had been done on
the monolithic tree that the best thing to do was to do a re-import with
the new code.

The libraries are in the same situation.

I repeat -- a transition to the modular tree cannot (repeat: not) be
done in one smack-bang transition which just unexpectedly dumps everyone
on to the modular tree.  The only smooth transition is a gradual one.

> > 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) ...

I used to use xapps, but I don't actually use any of the applications in
it, so not any more.

If you see bugs like these, please file it.  Most of the X developers
don't actually use Solaris, so if you want to contribute instead of just
non-specifically complaining on the lists, please file specific,
detailed bugs on Bugzilla, as per our processes.  Even better, just fix
it.

Yes, distributions will have to contribute manpower.  And I'm a
distributor, who has already sunk quite some time into modular packages,
and it wasn't easy.  I couldn't click my fingers and make it happen.

But that's too bad.

Again -- if you do not want a modular tree, please just say it.

> > > It may be better think about doing the xterm development in the Xorg
> > > CVS.
> > 
> > Please, no.
> 
> Why ?

I hereby propose Firefox (hell, the entire Mozilla suite) be maintained
in X.Org CVS, pending xterm being maintained in X.Org CVS.