Support of ancient servers in Xorg tree?

Mike A. Harris mharris at www.linux.org.uk
Tue Aug 17 01:28:35 PDT 2004


Alan Coopersmith wrote:
> The tree still contains rudimentary support for building ancient
> servers such as the old Xdec, Xsun, Xhp, etc.  How much do we
> care about this?  Should it just be put in the release notes that
> they no longer work?
> 
> I was doing a test build on Solaris SPARC this evening and forgot
> to set the BuildXFree86OnSparcSunOS flag, so it defaulted to building
> Xsun instead of Xorg.   This failed miserably due to various damage
> from Damage.
> 
> First it wouldn't link, since miext/damage/libdamage.a wasn't built
> since that was only added to some X server targets in
> xc/programs/Xserver/Imakefile.  Adding it didn't help because that
> won't build unless PIXPRIV is defined to give devPrivates in pixmaps,
> which is only set in xorg.cf, xfree86.cf, and cygwin.cf.  Trying to
> set BuildDamage NO and not build miext/damage failed because then
> misprite in libmi can't find the Damage functions it needs, since
> those weren't #ifdef'ed in.
> 
> With enough work, this can all be fixed, but the question is, is it
> worth it?  I doubt these ancient servers will be carried over to the
> modular tree - does anyone still use them today?
> 
> (If I were going to try to fix, I think the best way out of the above
>  mess is to define PIXPRIV by default and build miext/damage for all
>  servers instead of just the few that build it now.   #ifdef DAMAGE
>  around the libmi calls to the Damage functions would also be good.
>  I haven't followed through on that to see if it works or not though.
>  I don't think we have any spare machines running that still have
>  hardware old enough to use the Xsun server from this tree - we could
>  dig some out of storage, but I've got much better uses of my time
>  than that.)

If they don't compile, and nobody is building them from CVS to test if 
they compile and submitting bug reports and/or patches, then I would 
assume there isn't enough interest in the codebase to keep it running.

While it is great to have the entire codebase as portable as possible, 
and to keep the X server(s) running on as many platforms as possible, it 
only makes sense to do so if people actually _use_ the results on those 
platforms, and that they care enough about their Xfoo server to actually 
test it and get involved a bit.  It only takes one or two people to get 
involved, and minimal effort to report bugs.  So my personal opinion 
about other architectures, is if they have nobody actively building them 
and keeping them working, or volunteering a box for $favourite_old_OS 
for tinderbox, we should disable those things known not to compile (or 
known not to work when compiled) until someone comes forth on that 
platform as a maintainer/volunteer.

If part of the codebase is known broken for a full Xorg release with 
nobody stepping forward to fix it, and no current contributors caring 
enough about that platform to go ahead and volunteer to get it working 
again, I think that is a clear indicator of bitrot that should be removed.

Does this sound reasonable?




More information about the release-wranglers mailing list