modular -> monolithic

[Dave Airlie]

> 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.