x.org is Hacker Trash

[Eric Anholt]

On Fri, 2007-03-30 at 14:52 -0700, Kean Johnston wrote:
> > http://xorg.freedesktop.org/releases/X11R7.2/src/
> Which, I may point out, is incomplete.

Does it not actually contain all the modules that are considered part of
that release?  It was a long discussion, and I may have forgotten what
happened before, but at least in the future the plan is for
X11R7.whatever directory to contain hardlinks to all the individual
releases which are considered part of that katamari.

> No top level build script.

Meta-buildsystems are the responsibility of distributions.  Some
developers have tried to give you that anyway, with no waranties
whatsoever, with basically the results one could expect.  I was
maintaining jhbuild (which is a sort of top level build script) for a
while because that was a tool I was using to help me in development -- I
probably won't be any more, because I just get everything from my
distribution other than the 3 or so modules I'm working on.

> No
> top level README.

Yeah, that's bad.  Smack me if I screw up on that for 7.3.

> No XKB data files.

Not part of xorg any more -- it's got an active maintainer now.

> No pointers to other things that
> users *EXPECT* to be part of the distribution, like xterm (and yes I
> know its not maintained at freedesktop, but would it KILL you to put
> it in the app directory?).

We also don't put up libc, libexpat, Mesa, gnome, etc.  If you're being
a distribution, this is your responsibility(*)

> Any instructions given on building refer
> to things that aren't there (i.e util/modular is missing).

You need a util/modular package?  It doesn't seem like useful stuff to
package -- it's a bunch of random developer tools, most of which are
outdated.

> > You want more hand-holding than that?  Sorry.
> Yeah, a little. Just because the original poster came off a bit of
> a pratt doesn't mean he doesn't have valid points. The notion of
> a "modular" X is that modules can rev relatively independently of
> each other. Some people may be fooled into thinking they can watch
> xorg-announce and simply compile new versions of things. Not so.
> When things are announced, there is rarely a compatibility statement
> (this new version of FOO will work with releases A, B and C), the
> changelogs are so damned terse they are completely useless unless
> you are the actual maintainer yourself, etc etc.
> 
> I have seen absolutely NO benefit to the modularization of Xorg.
> And PLEASE don't throw out the so-often-repeated-but-meaningless line
> about "the fonts haven't changed in years, with the modular X
> you don't need to download them". If that was all you were trying
> to achieve (and they are by FAR the biggest chunk of non-modified
> bits) then that could have been easily kept aside from release
> tarballs. Instead, the modular X has destabalized the build, dropped
> support for scores of platforms, and made it all but impossible to
> do a new platform port (yes, you heard me. Consider what happens
> if you need a new version of libtool to make a platform work.
> With the current approach *EVERY* library, driver or other entity
> that uses libtool would need to be reved. You don't need ME to
> tell you what the chances are the release maintainers will rev
> all of that just to support a new platform).
> 
> So while I understand the knee-jerk reaction to dismiss the original
> posting as the rant of a loon, please do not fool yourself into
> thinking that for a lot of users, things have gotten very VERY much
> worse in the X world. X used to be a multi-platform, highly portable,
> well integrated suite of protocols, libraries and applications,
> that was developer friendly, and had an extremely long, well
> understood history and vast existing knowledge base. It has been
> replaced with a highly fractured, largely disorganized set of
> "stuff" that is glued together with good luck and bailing wire
> (to wit: the 7.2 release) that has lost a lot of platform support
> and replaced integral parts of the build process with tools that
> are maintained completely orthoganaly to the X sources.

I'm not just a developer, I'm a packager too. And for us, as I believe
for Redhat, Debian, Ubuntu, and other major distributions,
modularization has been a massive win.  Driver updates are going out
faster than ever in the history of X.  I'm now able to package both the
current stable server, and snapshots of the next release of the X
Server, so users that want to can give early testing, resulting in a far
better next stable release than would ever have happened otherwise (more
than that, it's resulting in us developing better protocols and ABIs by
cleaning up mistakes before we freeze them).

Certainly, if you're going to pick and choose modules instead of going
with a katamari, you're going to need more clue than otherwise.  This is
not that bad -- most distributions have someone with that clue, due to
having someone working on their distribution that is also an active
developer, who already knows from watching the lists which packages are
going to work well together (or knows when to ask if not, as I had to
recently when I was looking at updating inputproto).  Sometimes we're
wrong, as I was with damageproto at first, and things need to be fixed.
If you don't want to invest that time, you use a katamari, and still get
more frequent releases than X has had in the past.

With respect to libtool, the solution that FreeBSD has always had is
that its ports system runs libtoolize when appropriate to replace the
distributed libtool with a current one with tweaks for FreeBSD.  If
you're an OS which is supporting any libtool-using software (read: all
of them) and you need tweaks to libtool, you surely have this
functionality already.

If you really want building from tarballs to work on your system (so
your users can experience the joys of being packagers themselves, or
something), and that requires new autotools bits, we may consider
re-rolling tarballs with bumped version numbers.  We've done basically
that for the branded tarballs in the past, though it was more an
accident of the process than anything else.  I'm reluctant, in
particular if you're asking for it to be done with non-upstream
autotools bits, but I would consider it for 7.3 if there is a need.

> Was using git for branch management and making the fonts a
> separate archive really worth it?

git?  Absolutely.  It's at least done more for the speed and quality of
my development than anything else we've done, and more than any other
process improvement I've heard proposed as far as I can imagine.  We're
actually able to stabilize features on branches over a long period of
time, unlike with CVS where you had to race to finish your branch off
before it became essentially unmergeable.

(*) Mesa is actually the one piece we don't put up which we probably
should have been, or at least should have been providing clear
directions in the README for.  However, George Fufutos in his
awesomeness has recently provided patches that get GLcore being built
inside of mesa instead of inside xserver using symlinked mesa source, so
that requirement should hopefully be gone soon and this'll be a
non-issue for xserver 1.4 and up.

-- 
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/20070330/3982036f/attachment.pgp>