> This whole "partial" remonolithicalisation seems to not address the real > issue, which is a wrong general mindset, and instead this equals > sticking ones head in the sand and hoping that things magically go > away. > > There is no advantage to this as opposed to having a build test system > placing blame all the time. Each choice incurs pain, but one choice has > only pain and no undesired (or desired) sideeffects. So the problem with tinderbox is it is an out of line solution, the turnaround from tinderbox breakage to user caring is too low, also if tinderbox is broken by one person, subsequent breakages will go un-noticed so its a pain to get useful feedback for us out of it, we had a mostly working tinderbox, it went red, it stayed red nobody kicked anyone. The thing is we ship a server + drivers with a default config with everything that should build at this point, people check this out and try and build it, if it fails everything to fix is there in front of you on the machine you already have checked it out. I know personally i would never check all the drivers out from git as it is now, and I think a lot of people are the same, it is a royal pita to do this (typing 30 git commands or hacking build.sh). Like Mesa does the same thing with shipping drivers and rarely do drivers stop building or break even for hw nobody cares about like trident... Also the mantra that only people who care about drivers should fix them is crap as well, not everyone is a developer, we have lots of testers in a position to test those drivers if people port them, the testers are not programmers but can provide useful feedback if the drivers even build, so drivers not building doesn't mean no-one cares just that no-one who cares can do much without some X.org help. > But i think there are some things you are working towards that you > aren't immediately telling us. Things which would be rather hard to > stomach, unless it gets sneaked up on all of us. Everything after this is crap, I personally can't see that far ahead into the X.org future, nor do I try, I've no intention of culling anything or letting the SDK stop working, I do realise that with moving more things to the OS kernel(s) the X.org drivers will see less change and hopefully become more focused on rendering than modesetting which is after all what an X driver was originally meant to do. The kernel already does all this and address all your problems and has grown from being a project our size to a project a lot larger than us. You can with the kernel model build drivers outside the tree, we do it for the DRM the whole time. You can build in-tree drivers against installed kernel "SDK" headers. The kernel tree doesn't like shipping compat code in the kernel however we don't need to abide by that rule if driver writes want to keep it in their part of the tree... so all I can say you seem to fail to understand most of this... and prefer to think there is some secret agenda. so yes I prefer the kernel development model I always have and I will try to show X.org it is a better model not due to having hundreds of developer numbers but the developer numbers exist because of the model being so good... and yes this is all my own opinion and RH doesn't agree/disagree with any of it :) Dave. _______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg