File encoding is now UTF-8
ajax at nwnk.net
Sun Dec 12 16:03:07 PST 2004
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
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.
My concern here is that there's lots of enthusiasm for the _idea_ of the
modular release, but very little motion towards it. We're going to need an
Xpm package in xlibs that everyone uses instead of the copy in extras/; why
not start now? The more independent chunks we can rip out now, the better we
can see the interdependencies on the bits that are left.
If that means I have to be the one that says "cvs rm xc/extras/Xpm", that's
just a cross I'll have to bear. ;)
Obviously we need a group decision on this, my view is not holy writ, blah
blah blah. But if I have to threaten large pieces of code with deletion to
get people moving towards first a modularisation strategy and then actual
modularisation work, so be it, I'll kick as many defenseless puppies as
I'd also like to place a moratorium on adding any new applications or
libraries to the monolith. It's a bit inconsistent to claim both "we are
working toward a modular release" and "new programs and libraries go under
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg