Improving Xorg

[Enrico Weigelt]

* Joseph Garvin <k04jg02 at kzoo.edu> schrieb:

<snip>

> > Compiling is trivial, I really don't understand the problem you're 
> > having.
> 
> Compiling is far from trivial for the average user.

hmm, is the average user building Xorg completely by himself, 
without any distro ?

I personally didn't feel its complicated, but time-consuming to watch 
on the ./configure errors for missing dependencies, building these, 
with their deps, and so on. Since I've got my own dependency tracking 
buildsystem (little bit like emerge, but for crosscompiling) it was 
just the first time, until I had set up all the package descriptors.

The task to download and build all the packages in the right order
should be all doable in an Makefile (no need for autofool). 
I personally have no interested in it, so I won't participate here,
but if Cocoon wants to work on that, just let him do it. And once 
he got it working, his package should go into the next release.

I have the strange feeling, some people here are trying to stop 
him from his work, for some unclear reasons. I really see no valid 
reason for such behaviour. 

And @Cocoon: please don't let you demotivate by this. 

...

> First, the average user doesn't know what part of the tree they're
> interested in. Maybe they want the newer radeon driver -- but they
> probably have just been told their problem is "fixed in CVS." They
> figure like with most packages they just get the latest version of
> "Xorg." Even if they could just check out the latest radeon module, 
> they don't know if that also needs the latest kernel DRM or libdrm. 
> So they look up how to get everything from some distro specific 
> howto from a sticky topic on a forum.

Well, you raise another important point here, besides the build issue:

IMHO sometimes the releases take too long (not an Xorg specific problem)
Well, I appreciate the motivation to collect several patches and make 
releases that bring visible improvements, but this often is too long
for people having to maintain production environments / distros.

Perhaps some of you noticed that many distros maintain their own 
patches (I'm doing so too). Mostly these are small fixes necessary 
to get evrything built properly in certain environments (yeah, 
sometimes they're also fixing broken autoconf output). These things
(fixing our releases) should't be the job of the distros, but our.

Since many projects suffer from this problem, I started to form 
an distro independent QM project for exactly this job - collecting 
hotfixes for certain releases. This should satisfy both sides - 
an central point where all people (distros and self-builders) can
fetch their hotfixes to repair broken releases (no need to fetch
an probably broken CVS/GIT snapshot) and letting the upstream 
devs in peace, so they can concentrate on their (bleeding-edge) 
work. I announced this several times here, but with no noticable 
interest :(


Uh, we're getting from one issue to another ...

> >   Do you really want to build all the unrelated packages Xorg 
> > used to include in it's monolithic monstrosity?  Why would you ever want 
> > to recompile libXt for example?  Aren't you more interested in the 
> > server itself?
> >   
> Because they don't know any better and there's no guide on how to do
> that. A kernel menuconfig like system would be a lot better.

ACK. Although I personally don't need this, It seems to be a good
thing for people not having an automated buildsystem in their back.

So, please, could the people who are interested on it just work on
that and all the other leave them in peace ? I don't see any value
in stupid flamewars.

If such an project shouldn't be hosted on Xorg, for some reason,
I'd be glad to offer hosting resources (bugzilla,wiki,cvs,...)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------