I’ve started using the Pegasos as a tinderbox for X.Org — take a look. It’s spyder-ppc-6_8 for now, because it’s building what will become the 6.8.2 release in the next week or two. After that, it’ll start following CVS HEAD again. I had it set up as a tinderbox a while back and caught a few build errors in the one or two nights I had it running — I’m hoping to continue this trend to keep X working well on PPC.

Dylan, here’s your first response (I hope).

Planets are great ways to form blog communities and educate both the authors and third-party readers. I love reading Planets because I see things I already knew I’d be interested in, mixed together with things I had no idea I’d care about before I saw them.

They’re fantastic tools for growing closer as a community, for increasing potential and actual collaborations and for broadcasting current and future work and plans.

You say that function is more important? I say not. If the code isn’t clean, neat and beautiful, it isn’t a pleasure to work with. Therefore I don’t work on it as much.

So, I’m spending some time beautifying the xorg-x11 ebuild in hopes of:

• making work on it more fun for me, so I spend more time on it
• making work on it more efficient for me, so I get more done in the time I spend
• making it easier to understand, so people are more willing to help me out

Note the emphasis on “me” here — open-source development scratches an itch, remember that.

I’m pleased to announce that 6.8.2 RC2 works with Gentoo on x86, ppc (Pegasos) and sparc. That’s all I’ve got.

Xorg 6.8.0-r4 hit stable last night on sparc, x86 and mips. I’m hoping it does the same on amd64 before our 2005.0 release snapshot, but there’s some serious time crunch. I’m generally pretty pleased with how it turned out.

The next step of the migration will probably be /usr/X11R6/bin -> /usr/bin and /usr/X11R6/include -> /usr/include/X11 to finish things off, but I don’t expect it will happen until 6.8.2. It will definitely be nice to just have /usr/X11R6 -> /usr. First, however, I need to fix my highly specific migration function to be more robust and generalizable to anything. Actually, 6.8.1.90x’s might be a good opportunity to work on this, so 6.8.2 could also signify the lack of anything in /usr/X11R6.

Spent tonight installing Gentoo on the Pegasos (again…). After the glibc breakage, and a few installs back before I had it fixed, this is getting pretty familiar. I have a feeling NPTL is broken on PPC, so I’m going to stay far away from that, this time.

Also, I got an email today asking why I pulled xfree. It was pretty much just me trying to maintain xfree, xorg 6.7.0, 6.8.0 and 6.8.2RC’s all at once, in my free time. I keep trying to recruit more X people, but largely without any luck.

He said old Matrox cards were broken with xorg. Assuming “old Matrox” means G[24]XX, I proved that false by pulling out the G400 MAX I had stashed away for a rainy day. It works perfectly. I’m writing this from 6.8.2RC2 on the G400.

One thing I am pleased about from today is that I gave editbugs power to ajax on Gentoo’s Bugzilla. Hopefully he can help get the upstream bugs out of our Bugzilla and into somewhere useful.

I’m working hard to get xorg 6.8.0-r4 ready for our 2005.0 release, so we can release it with the lib stuff moved to /usr/ from /usr/X11R6/. I got reports that the migration function now works properly on amd64, which I’m quite happy about. I spent quite a while yesterday staring at it. I’m working on getting access to one of our amd64 boxes, so I don’t have to rely on hearsay that things work properly.

It also looks as if sparc’s going to start building with dlloader by default. I’d like all the non-x86 architectures to do so, since they don’t have the problem of dealing with binary drivers, to my knowledge. Speaking of dlloader, check this out.

I’ve been working on the migration function from /usr/X11R6/lib to /usr/lib, and the architectures with multilib have been annoying the hell out of me.

First, the developers who should know why it’s done the way it’s done seem completely inaccessible. Second, it doesn’t match the way the FHS suggests. Third, people who know something about multilib have told me that a symlink to or from lib is a hack.

But mainly the reason I’m so annoyed it’s done the way it’s done is that I assumed (stupid me) that we’d be doing it how the FHS did, and now I had to make a huge hack to compensate for differences between versions.

Spent tonight’s dev time finishing up a draft of a guide for Gentoo devs mentoring new recruits. I’m satisfied, although not completely happy, with it. Next on the list are similar guides targeted at the recruiting team and the recruits.

Also read a good book by Robert Newcomb called The Fifth Sorceress. I’ve read it before, but I forgot most of it. It’s the first in a series.

The Wikipedia entry on Frederick Brooks’s famous book, The Mythical Man-Month, has a superb summary.

I’m looking at some other projects for examples of how they run things, in addition to referring to a few books I’ve got lying around. For anyone interested, the books are Free/Open Source Software Development, a collection of papers edited by Stefan Koch, and The Cathedral and the Bazaar.

Here’s a few of the major points, some drawn from Koch’s book. Many of them may seem self-evident, but they’re easy to forget about when you’re trying to figure out what to do with 250+ developers.

• Developers prefer more loosely controlled projects with a flat hierarchy, relying on individual autonomy, tacit norms and self-organization rather than commands, control and explicit rules. FreeBSD and Mozilla projects rely on requesting contributors to follow rules of conduct rather than technical control mechanisms, although Mozilla was moving toward a strongly controlled modular setup.
• On a related note, the release plans are the only plans. There are no plans on more detailed levels and no timetable for the contributions that will eventually lead to the next release.
• Community testing is essential for finding and removing bugs. Keeping the developer and user communities close-knit aids bug-fixing, as ESR writes: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.” Despite resistance from some users who want to remain purely users, we need to keep our community cohesive between developers and users to get the benefits of the open-source model.
• Openness is a primary principle. In nearly all cases, code, lists, bugs, and tests are available to everyone.
• A key motivation factor for contributors is quickly seeing the results of their work. We need to keep the bureaucracy required to contribute from becoming too complicated and time-consuming, or we will lose potential developers.

Next time, I’ll talk a little bit about each project’s rules and recommendations.

An annoying bug with hardened systems keeps cropping up. I wish it would just go away, hide in a corner and die.

In other news, I’m working on a list of 2005 goals for the desktop project. It’s sometimes difficult to separate desktop goals from Gentoo-wide goals — perhaps I shouldn’t try. One is simply a subset of the other.

Gentoo does a great job of “microgoals” within individual projects, but it has trouble tying them together into distribution-wide “macrogoals.” As a result, a lot of times it seems as if we don’t have a cohesive vision to base our progress on. Improving that is a personal 2005 goal.

Over the next week or two, I’ll probably be writing more about how we can create cohesive goals and improve our development methods, and other, established open-source projects we can learn from, such as Mozilla and FreeBSD.