modular -> monolithic

[Eric Anholt]

On Mon, 2008-01-21 at 16:42 -0800, David Miller wrote:
> From: Eric Anholt <eric at anholt.net>
> Date: Mon, 21 Jan 2008 16:31:33 -0800
> 
> > If a user is asking "how do I build every xorg module?", they're doing
> > it wrong.  But when they ask "how do I get updated xorg bits?", we're
> > answering "here's how you build every xorg module", when we should be
> > telling them "install xorg from your distro, then build server and video
> > driver".
> 
> That's such a load of crap.
> 
> For me personally I wanted to build everything because I wanted
> to make sure everything built properly on Sparc and that I could
> get radeon working on my workstation with libpciaccess.
> 
> As a result I was able to fix several bugs and get it working.
> 
> So should I just go take a long walk off a short pier?  That seems
> to be what you are suggesting.

If your goal is to build the whole tree so you can make sure everything
xorg has builds on your platform, have a party.  We should keep
build.sh/jhbuild/whatever and the instructions around for those who are
doing that.  And we should find a credible tinderbox solution so that we
can smack lazy people (mozilla tinderbox is not that solution) before
you even get to it.

But the first thing that the average adventurous user (that is, not you
or I) encounters when looking for how they get an updated version of
their driver so they can get X to start should not be "here's how you
build every xorg module and if one doesn't build submit a patch before
continuing."  Unfortunately, that's all we're offering on the wiki
currently.

> This kind of thing is exactly how you deter potential contributors.  I
> can't count the number of people who have contacted me privately and
> told me that the attitude of many Xorg developers is why they never
> really hacked anything major on the X server.
> 
> Anyone should be able to check out the whole tree and it should build
> cleanly.  Anything else is a bug.
> 
> I am hugely disappointed in the even remote suggestion that leaving
> some portions of the tree in an unbuildable state is somehow OK.  If
> you can't get past that simple premise, the rest of the discussion is
> absolutely pointless.

Some portions of the tree, sure, using the rough criteria of hardware
that we can't find any instances of and therefore can't test.  But using
that as the metric, I think between 3 of us server folks we've probably
got every can-be-put-in-an-x86 video driver covered.

I do think that the input and pciaccess merges were handled badly and I
would like to see us never, ever repeat that.  I had my finger on the
button for reverting pciaccess at one point.  I kind of regret not doing
that just to set precedent.

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080121/161a0724/attachment.pgp>