modular -> monolithic

[Matthias Hopf]

On Jan 20, 08 16:27:55 -0800, David Miller wrote:
> From: Matthieu Herrb <matthieu.herrb at laas.fr>
> > Beeing able to build drivers outside of the X server was one of design
> > goals even for XFree86 4.x. This is really something we need for various
> > reasons that I can remind if necessary.
> 
> People can still do that even if we put the drivers all back
> into a monolithic tree.

And people still can build and verify all drivers by building them
outside if necessary. Heck, what do we have build.sh for? And Egbert
announced that he had written a new build system that even tracks
dependencies correctly, with little to virtually no interest on the
mailing list at all.

> > Last point, one of the goals of the modularization effort was to make it
> > possible to contribute to X.Org without having to build the whole tree.

And it really works very well.

> And this is exactly why the build of half the drivers tend to
> be broken at any given point in time.

No. Half of the driver ten to be broken at any given point of time,
because developers change internal APIs without validating that all
users of these APIs are updated accordingly as well.

Sometimes APIs are even broken in such a subtle way, that there is no
way e.g. in the driver code to actually work around these breakages with
additional autohell logic (e.g. the most infamous XVideo API update for
Composite). It would have been too easy if there was a #define for
testing this.

> If you don't enforce validation of the build of the drivers there is
> no quality, and people will check in all kind of shit that breaks
> things left and right.

Here I agree *very* much with you.
But how do you do that? I think a tinderbox-like build system would
improve the situation a lot here, though a lot of statements about the
quality of tinderbox itself have been stated on this list.

Having a monolithic build system doesn't necessarily change this. Those
developers who don't believe in thorough API build tests won't
necessarily build all drivers in the monolithic tree as well.

> And frankly, what you say isn't effectively how things actually
> work.  You do have to check out large chunks of the various GIT
> trees (and it's non-trivial to figure out the dependencies,

Sigh. On the fetch-and-build side we really have work to do. Maybe we
should check Egbert's solution again, I thought to remember that it even
checked out the necessary trees if told to.
This certainly has to be documented better. I'm not pointing to anyone
here, just considering the state.

> and the build.sh script is out of date half of the time) in order
> to do X server development or even work on a single driver.  So

I do driver development on a daily basis, and I don't even work against
current git head. The SDK from the last release is working well enough
in most cases. This might not be the case for the intel driver, though.

> the non-modular tree in fact makes it HARDER to contribute to
> the Xorg code base, because getting the build purely out of
> GIT to work is so damn hard.

Err - I think you meant non-monolithic here, right? In your
argumentation line, I mean :)

> In kernel land, whilst we don't require people to validate the entire
> build with everything enabled, we have the people who do the patch
> applying and code checkins who do those build checks and punt the
> patch back if it breaks some part of the build.

We don't have that people here at X. Heck, even posted patches are not
validated or checked in. So the kernel development model won't fit
without the necessary people willing to do that.

> And right now, since the mentality to not break the build does
> not exist, the only viable solution is to force it upon people
> by unmodularizing the tree.

Which doesn't solve a thing.
Sorry for being destructive (and not constructive), but I just don't see
what this would help. I also don't see a technical solution at all to
this IMHO social problem. A tinderbox like solution might help, though.

> The current situation completely sucks.

Ok, something to agree on.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de