File encoding is now UTF-8

[Ely Levy]

On Sun, 12 Dec 2004, Adam Jackson wrote:

> On Sunday 12 December 2004 17:10, Daniel Stone wrote:
> > On Sun, 2004-12-12 at 17:06 -0500, Kristian Høgsberg wrote:
> > > Adam Jackson wrote:
> > > > On Monday 06 December 2004 09:28, Egbert Eich wrote:
> > > >>That's not entirely true. We 'inherited' Xpm because nobody else feels
> > > >>responsible for it any more. Now we have to worry about all the
> > > >> security problems in this lib.
> > > >
> > > > So what you're saying is, we should push the Xpm security fixes to the
> > > > copy in /cvs/xlibs, and delete it from the monolith, so we don't have
> > > > to repeat the 6.8.1 release ever again.
> > > >
> > > > Anyone who objects to me doing this on HEAD has until (let's say)
> > > > Wednesday Dec 15 to complain.  If we're serious about doing 6.9 as a
> > > > modular release we need to start evicting code from the monolith _now_.
> > >
> > > Is this the general way we're going with the libs when we modularize the
> > > tree? My impression was that we would start from the current monolithic
> > > tree and split that out into separate libs and apps.
> >
> > Xpm is a special case in that it's totally dead code.  I don't believe
> > there are actually any changes -- apart from the saga of continuing
> > security updates -- between the modular and monolithic versions.
>
> We don't really want a monolithic tree corresponding to 6.9, do we?
>
> My view here is, we should kick code out of the monolith as soon as possible,
> because that way we can stop thinking about it.  The code that will require
> the most care is the server and the important client libs, and there we're
> justified in maintaining parallel trees for a while.  The pieces that no one
> cares about - libXpm, pretty much every Xt and Xaw app - should be pushed
> into xapps or xlibs and then nuked from xc/.  That way, at any given time,
> you can look at what's left of the monolith and know exactly what still needs
> modularisation.

I couldn't agree more.

> xterm.  xterm is a shining example here.  xterm has an upstream maintainer.
> Why are we wasting cycles merging it into the monolith?  Why does bug #1979
> even exist?  Nuke it, WONTFIX, full stop.

Yep, I said it many times before IMHO xterm shouldn't be part of xorg at
all. It should have its own release by Tomas.
I mean it's not part of xorg now we are just bundeling someone elses
software. If we do need a terminal I suggest we ask some other project
to join in, xterm is very stuck development while other terminal seems to
florish and add nice new options. like tabs support or full bidi/unicode
support encoding changing and so. One of the nicest thing about xterm
is the fact that its light so I don't think we should give up that,
but we should still more forward.(mterm?)


Ely