Re: Rationale for package removals?

On Mon, 9 Sep 2002, Thomas Dodd wrote:

>>Indeed, and by removing Xconfigurator, people will now file 
>>requests for enhancement for these missing features (just like 
>>  
>>
>>you're about to most likely <grin>) so that we can add these 
>>
>They were never added to Xconfigurator either. About the only RFE
>I would have is Include xf86cfg, or at least ALL the functionality it has.
>I'm usually using newer versions of X/DRI and the kernel. I usebuild the
>SRPM and build myself (and don't file bugs since my setup is unsupported:)

No.  xf86cfg is gone.  I purposefully removed this.  Our 
supported X configuration tool used to be Xconfigurator.  Now our 
supported config tool is redhat-config-xfree86.

Why remove xf86cfg?  Because if redhat-config-xfree86 does NOT 
work, I want people to file bug reports about it, so that it can 
be fixed.  I want to know what features that people would like to 
see added to it.  I _DONT_ want people to just go "oh well, 
redhat-config-xfree86 didn't work for me, I'll just try xf86cfg" 
because then bugs never get known or fixed.

That is why XFree86 3.3.6 existed for so long.  Because it was 
_there_ so people would just go:  Oh, 4.x doesn't work, I'll just 
use 3.3.6 instead of reporting bugs and getting them fixed.

I'll wager that had Red Hat Linux 7.0 shipped without XFree86 
3.3.6, that by the time Red Hat Linux 7.1 was out, most of the 
hardware not supported by 4.x in 7.0 would have been working in 
7.1 because people would have worked on it rather than just 
settling for legacy 3.3.6.

In other words, I believe shipping the old stuff as a crutch has 
hampered XFree86 development.  Likewise I don't want 50 config 
programs to hamper the development of our supported config tool 
redhat-config-xfree86.

If someone truely does want xf86cfg, they can of course build it 
by hand, by recompiling the X server.  I made it conditional 
define in the spec file wether it is included or not.


>I always thoughh Xconfigurator sucked too.I liked XF86Setup.
>It had problems, but looked like a good start.

I liked XF86Setup a long time ago too, particularly because it 
was graphical.  It was fairly ugly though compared by today's 
standards.  So is xf86cfg.

In order to make things not ugly, and not suck, we need people to
use the new stuff, test it, and report bugs.  Then we can work
hard on improving the modern tools to do what people want, look
nice, and also (hopefully) not suck.

PLEASE, report bugs, and feature requests for 
redhat-config-xfree86.  Alex is great with fixing bugs that have 
been reported fairly quickly.  Feature requests get prioritized, 
and not all requests will be added of course, but I suspect most 
sane requests will be added at some point.


>>>I agree. XF-3.3.x was kept too long.
>>>    
>>>
>>You're on my Christmas card list now.  ;o)
>
>Of course I was using the Rawhaide XF86-4.0 tree as soon as it
>was up. And 2.3 kernels before 2.4 was released. Now
>if only 2.5 would become usable...

And XFree86 4.3.0...  ;o)

Take care,
TTYL


-- 
Mike A. Harris		ftp://people.redhat.com/mharris
OS Systems Engineer
XFree86 maintainer
Red Hat Inc.