Problems with X.org and incompatibilities with in-house software

[Richard Brown]

Alan Cox wrote:
>>> To our much dismay we have recently found after attempting to install 
>>>       
>> new Linux boxes that these extensions no longer appear to be available. 
>>     
>
> PEX was dropped in what was it 2004, so six years ago... taken you a
> while to notice and it was dropped because nobody could actually find a
> single user of it. By the time PEX stuff ever approached any real
> implementation OpenGL had buried it because of the need for things like
> texture mapping.
>
> But then if you wanted people to believe you were genuine you wouldn't I
> susppect be posting from what the analysis tools say is a new google
> account and without naming the company. You'd have approached X.org as a
> company through management and had a rational discussion about the best
> way to support the extensiosn you need (or had that discussion with your
> Linux vendor) and spent a lot less by making sure the commercial
> justification was there for someone to support it.
>
> Still if you'd rather rewrite all your code, pay Microsoft zillions and
> not pay a consultant to do the updating on the modules you need for
> resubmission (or even pay an undergrad minimum wage to knock you off a
> package of an old build) don't let me stop you ;)
>
> Alan
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>   
Ok, indeed. We dont really use PEX that much, more into OpenGL these 
days so its not important. I certainly wouldnt ask a lot of effort to 
support it. Only if it could be re-enabled with simply adding it back 
into the compile process would i suggest that be considered.

I would say the same about the other extensions. if it requires a lot of 
major work to get those working again, okay, i can understand that, no 
problem, i would not ask you to commit such an effort. But to just 
remove something because "we dont like how that looks there", which is 
working fine however and in a useable state, does not make a lot of 
sense. Why not just leave it in? "We dont like how something works", or 
"we dont *think* anyone is using this", are not good reasons to remove 
support. There would have to be a severe problem with the code, broken 
code, that would necessitate a extension being disabled. So of these 
disabled, removed extensions. How many of these are disabled as a result 
of actual broken code, vs, how many are disabled because, "we don't like 
how it looks"?