[Gentoo] Overlay in layman

I just added my Portage overlay to layman. It’s got a few live git/cvs ebuilds for X-related things including xorg-server, some video drivers, mesa, xgl, compiz, cairo, glitz. I try to keep them as vanilla as possible and ready to go into the main tree, which distinguishes this from other overlays.

Also it’s got a bunch of biochemistry-related software that I use in my day job but isn’t yet ready for the main tree, and the Sun Studio compilers (but the IDE itself doesn’t work yet).

[Gentoo] Tip: Finding and fixing warnings made easy in Portage

Losing warnings in all that compiler output? Try this quick tip out!

Open up /usr/lib/portage/bin/emake and change this line:

exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@"

to this:

exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" > /dev/null

This hides all the useless output you don’t care about that goes to standard output. You only care about what goes to standard error, so only warnings, errors and similar show up. It also has the side effect of reducing the CPU used to print tons of output on the screen.

[Gentoo] Upstart: A new paradigm in services

My LWN subscription again made itself worthwhile today in an article (subscribers only until 7 August or so) about upstart, a new take on the init daemon. It’s event-based rather than dependency-based, as Gentoo’s init system is. What’s this mean? It figures out what to do and how to get there instead of being told, and it does a better job of dealing with today’s additions and removals of hardware while the system’s running. In comparison with initng or runit, other init replacements:

Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot.

A recent thread on the gentoo-user mailing list discussed initng and runit. Here’s my take on the whole thing: initng and runit are rethinks of sysvinit, but upstart is a rethink of the whole method of dealing with services and jobs.

Another associated boot-time speedup suggestion comes from Jens Axboe’s fcache patch, which aims to make the boot process completely linear on disk. One Gentoo user quoted a startup time for a “fully loaded” laptop of 13 seconds when combining initng and the fcache patch. It would be interesting to couple this with sys-apps/readahead-list. For Gentoo users, ck-sources already contains the fcache patch.

[Gentoo] Compartmentalizing open-source development

Erich, indeed you’re right. You’re not the first one with this idea.

As long-time Gentoo developer George Shapovalov wrote on our private developers’ list:

There are scientific publications reporting existence of a “magical number” 😉 of people involved in a project that maximizes the efficiency. It is actually even stronger – you effectively cannot go over a certain number of people without restructuring. Here is the link to the primary paper: http://www.bbsonline.org/documents/a/00/00/05/65/bbs00000565-00/bbs.dunbar.html

In short: this is due to the way we are “wired” as species, so this is perceived a hard limit in a sense. The trustees are falling, by the nature of the stuff they do and how they communicate, into the “small group” region, and the magical numbers for that are 6-8, max 9. (That is maximum efficiency at ~7 and you cannot go over 9 (of actively participating people) realistically).

So, it’s pretty easy to do the math here. 350 > 9. Conclusion being that the large-scale gentoo-dev list is not the best way to develop — rather, smaller lists and projects are. But then, how does one accomplish anything project-spanning? Presumably by resorting to a republic, as Michael Cummings said, the decision could be made by a small enough group of people representative of Gentoo as a whole.

[Gentoo] Democracy: No silver bullet

I started my fourth year as a Gentoo developer in June, and Gentoo’s changed a lot since I started back in 2003. We’ve become a drastically more democratic organization. But the question remains — Is this a good thing? When I think about where Gentoo was when we turned into a democracy years ago, and where Gentoo is now, I don’t see much of a difference on the large scale. We lack any global vision for where Gentoo is going, we can’t agree on who our audience is, and everyone’s just working on pretty much whatever they feel like.

When I joined, Daniel Robbins was in charge, period. Seemant Kulleen and Jon Portnoy were basically his lieutenants. What Daniel said was what happened, and woe to anyone who angered him. This generally worked out pretty well, but as Gentoo grew, it didn’t scale. Everything significant still had to go through Daniel for personal approval.

Shortly after I finished training and became an “official” developer, Gentoo gained its first real structure via Gentoo Linux Enhancement Proposal (GLEP) 4 — “Gentoo top-level management structure proposal”. The GLEP process itself was quite new then; GLEP 4 was really only the second proposed GLEP (the first two were details related to the GLEP process) and the first one that was accepted. Its goal was to improve communication and coordination as well as increase accountability.

GLEP 4 formalized a hierarchy of so-called “top-level” projects — between 5 and 10 major areas into which everything in Gentoo could be divided. Daniel appointed the original project managers, who served under him.

Democratic elections entered Gentoo when we realized that we needed to create a new top-level project for all the desktop work, because it didn’t fit into any existing project. Since managers already voted amongst themselves on GLEPs, it seemed like a natural extension for them to vote on a new manager. The call for nominations is archived online. I’d been a developer for around six months at this point, and by then I was the lead X maintainer. Brandon Hale was active in maintaining window managers and other miscellaneous applets and such. Turns out that the vote tied, so we became co-managers.

I didn’t realize it at the time, but that was the beginning of a very slippery slope.

Gentoo used to be a courteous, friendly development community where nobody was afraid to speak his mind for fear of insult and injury. I see a clear correlation between the growth in democracy and the departure of courtesy. Once people are empowered to vote on every decision, rather than just having their discussion taken as input in a decision, they get a lot more vehement, argumentative and forceful about getting their way. Flamewars and loud arguments going on for hundreds of posts have become commonplace, despite the occasional outcry. Here’s one such outcry, on March 20, 2006, to the private developers’ list:

What I’ve seen for the last 18 months or more is a general degeneration
in the attitudes of developers for their fellow developers.
When I
joined, the attitude of people was friendly and welcoming. I screwed
up a couple of times. I didn’t get my ass handed to me. I got picked
up, and comforted. And taught and tutored. …

So, we split from the Gentoo Technologies company, to a community owned
Gentoo Foundation. And now everyone was empowered. Everyone has a
voice. Some louder than others. The unfortunate thing is that with
this empowerment came a bit of assholishness.
With rare exception,
we’re pretty much all guilty of that. Someone makes a spelling error in
a commit, and that leads to flamefests on irc and mailing lists and blog
entries. And so on, ad nauseum.

Frankly, I’m sick of it. It’s burning people out. We’re burning
ourselves out by being this way. It’s time to stop this shit. To
everyone reading this, you’ve arrived at the important bit. From now,
please try this little thing. When you’re on the mailing lists or the
fora or irc channels or in /query or somehow in the gentoo ‘verse,
please try, just try, to be a little bit nicer to the people with whom
you’re interacting. That’s all. Have a little respect (even if not
deserved!). Listen a little. Hold back the snide comment, the
sarcastic remark. I don’t mean to get all Oprah on you all, but I hope
you see my point — just be nice for a change.

The vocal minority often gets its way, despite 99% of the other developers being happy with any given situation.

The problem got so bad that our Developer Relations team wrote up an etiquette guide. Unsurprisingly, the same vocal minority that generally behaves like an ass and violates said etiquette guide erupted in flames over it, and it ended up fading into an existing but largely irrelevant piece of writing.

Around the same time, more cries of “Democracy!” and “Eliminate the cabal!” forced developer relations (devrel) to come up with a huge, bureaucratic, court-like system for disciplining pretty much the same group of people again. Everyone treated it like a world of extremes of good and evil, where democracy is absolutely good and purity, and anything other than that is evil. This added bureaucracy has essentially rendered this side of devrel powerless, meaningless and useless.

All in all, the vocal minority has done a splendid job of becoming more influential, crippling Gentoo’s ability to do anything at all about its members, their flames, their outstanding work at ruining people’s fun and enjoyment of Gentoo, and their waste of everyone else’s time.

How can we do anything about this? As people such as Mike Auty have pointed out, the problem could be with the increasing barrage of rules, regulations and policies to which we’re expected to adhere. Take a look at the FreeBSD committers’ rules. Rule one is “Respect other committers,” and rule two is “Respect other contributors.” Take a look at the importance of courtesy and care to avoid creating long-term disagreements in rule one:

Being able to work together long term is this project’s greatest asset, one far more important than any set of changes to the code, and turning arguments about code into issues that affect our long-term ability to work harmoniously together is just not worth the trade-off by any conceivable stretch of the imagination. …

First calm down, then think about how to communicate in the most effective fashion for convincing the other person(s) that your side of the argument is correct, do not just blow off some steam so you can feel better in the short term at the cost of a long-term flame war. Not only is this very bad “energy economics”, but repeated displays of public aggression which impair our ability to work well together will be dealt with severely by the project leadership and may result in suspension or termination of your commit privileges.

Or how about the Ubuntu Code of Conduct? The first two rules are “Be considerate” and “Be respectful.” Again, note that these rules are actually enforced. As has been pointed out on the Gentoo development list, you can have respect without courtesy. But Gentoo needs both! One just isn’t good enough.

But what about Gentoo? We don’t have any overriding principles like this from which all of the standards for behavior derive. Instead, we have a large document explaining specifically and in detail what’s allowed and what isn’t, and even that is ignored. Because of the bureaucracy and the lack of respect for devrel’s role, we’re effectively powerless to do anything when people behave in a way for which the FreeBSD project’s leadership would kick them to the curb.

I’m not the only one to suggest that a democracy isn’t the most productive way to run Gentoo. When people wanted to change in how Gentoo was run, democracy was the only option considered, rather than simply changing the leaders. There’s an ongoing assumption that if problems exist, it must be somewhere in the structure rather than in the people.

If I could go back in time a couple of years and prevent this democracy from ever happening, I would. If I could fix these problems myself, I would. But it requires buy-in from the entire Gentoo community if we’re to do anything about it.