Everybody who went to LCA entered their distro, editor, and shell upon registration. Peter Lieverdink posted graphs of the results.
Gentoo made an excellent showing, coming in 4th after Ubuntu, Debian and Fedora. This is particularly neat because LCA attendees fit Gentoo’s target audience really well: developers and power users.
Thanks to Daniel Black for the link to that graph.
This won’t be a long post, because I’m tired. Sorry for the dearth of posts on here, but I’ve been busy writing other things—see below.
For anyone who hasn’t heard, I took over as lead of Gentoo’s public relations efforts a little over two weeks ago. Three days earlier, I wrote an LWN article concluding that Gentoo isn’t falling apart, but it’s totally failing to communicate. After writing that article, I realized that somebody had to step up to deal with this problem—who better than me?
My focus right now is showing people that Gentoo development is just as alive as it’s ever been. I’m doing this by opening windows into development through more frequent news postings, with links to discussion forums to respond to the posts. Doing this, combined with writing to people (“You will”) rather than about them (saying “Users will…”), will help build better relationships with our users.
Another part of improving the perception of a lively, active community is updating the look of our website. The old website redesign never made it to fruition, so a few of us have begun taking a look at how far it got, what happened, and what to do now. At a minimum, I’d like to make some slight changes to give our site a face lift. The design hasn’t changed for 6 years now, and it shows.
One major, easily fixable problem with our website is that there’s no obvious place to go for users who want to contribute. There should be a big “Get involved!” or “Help Gentoo!” link right up at the top of the page, next to “Get Gentoo!” All this requires is a little webpage that describes all the ways people can help. In fact, the whole website isn’t task-oriented enough. This needs to change.
In the future, I’m going to begin improving the “press” aspect of PR, based on my notes from an excellent talk by Josh Berkus at OSCON 2006 on public relations for OSS projects. The main ideas here are providing a press kit for reporters with all the basic info they want, building relationships with local reporters by using local Gentoo contacts, putting together some case studies of people and businesses using Gentoo in interesting ways, and improving our process for creating and posting news and press releases.
Finally, any Gentoo users can help improve Gentoo by simply advocating it to Linux users you know, giving demos and talks at Linux user group meetings or conferences, promoting it in articles, or writing in your blog about something Gentoo does really well.
That’s a question a lot of people have been asking lately, with the news about the nonprofit foundation, the lack of news updates on the homepage, and the canceled release. I answer it in a short LWN article.
I just committed xorg-server 1.4.0.90, which is a prerelease for 1.4.1. Here’s the Gentoo ChangeLog:
Bump to 1.4.1 release candidate. It’s gotta be an improvement over 1.4, so i’m letting it go into ~arch.
(#192221) ‘xorg-server-1.4 – keyboard LEDs do not work’ fixed upstream.
(#201047) ‘xorg-server 1.4 no longer loads xmodmap via xinitrc properly’ fixed upstream.
(#197104) ‘xorg-server-1.3 and 1.4 consumes 100% CPU, locking the keyboard, apparently triggered by opening an OpenOffice pulldown menu’ fixed with patch from master branch.
(#196019) ‘xorg-server creates unnecessary file /etc/X11/X11/Xsession.d/92xprint-xpserverlist’ fixed by not installing the same file twice to 2 different places (Andy Crook).
(#195886) ‘xorg-server-1.4.0-r2 built with hal USE flag crashes on shutdown if dbus service is not running’ fixed upstream.
(#195551) ‘xorg-server-1.4 fails to build w/kdrive on amd64’ fixed with Makefile.am patch designed for easier sed but unsuitable for upstream because the line gets too long (Michael Gorse).
(#194503) Don’t spit versions when showing drivers to rebuild via qlist, and also provide a command for people to do it themselves later.
The upstream X.Org change list is available here.
I’ve been talking with Lance lately about setting up a good development machine, and GCC 4.3 (still unreleased) came up so I checked out its changes. Here’s a few I found particularly cool:
I’m already using GCC 4.2, but I hadn’t really looked into its changes either until now:
LWN just published my story of this name as premium content. I ran a number of analyses on Gentoo’s CVS commit history, kindly provided by Robin Johnson, to look at what happened to our developers and our commits over time. If you want to know the results now (rather than waiting until the content becomes free), subscribe to LWN—the best Linux and open-source software news.
Gentoo is good. How do we make it great?
Over the past year or so, I’ve read a few books, and I want to use those ideas to build a better Gentoo. The books:
I plan to write a short series of posts discussing the lessons in these books and how to apply them to Gentoo. In this post, I’m going to summarize the concepts of “Good to Great.” I’ll discuss how we can apply them to Gentoo in a later post. The book explains what it takes to transform a good company into a great one. It’s a comparison of companies that made a transition from good to great (thus the title) with companies that remained merely good. Jim Collins and his group reduced the differences to a remarkably small set:
The right people have the right innate abilities and character traits, not necessarily the specific knowledge and skills. For example, look for work ethic, dedication, and problem-solving ability, not ebuild-writing skills and knowledge of bash.
The resource engine is a combination of time (how well we attract contributors), money and brand (how well we create a community), drawn from an accompanying monograph for the social sectors.
That’s my ranking in the “Top Linux blogs,” according to Don Marti. I’m a little confused how that happened, given how rarely I’ve blogged lately. Perhaps he knew I had some more good ideas in the pipeline. =)
I recently posted about making Gentoo a better tool. A requirement for being a good tool is being a tool that doesn’t break—thus, we need to improve our quality to a more reliable level. I’m going to mention a few ideas to start this discussion, which I hope the rest of our community will participate in.
First, we essentially have no code review. About the only time any code in Gentoo is reviewed is before and during a developer’s training, with a notable exception being the requirement to post eclasses to the gentoo-dev list. Increasing our code review ought to result in an increase in quality, in ability to justify code in words, and in a stronger community of contributors.
How do we increase code review? One idea is to require reviewer approval prior to committing, but this isn’t the best answer for Gentoo. We’ve always been a pretty open community. Developers aren’t prohibited by ACL from committing anywhere in our ebuild repository, so I don’t think they would accept additional requirements that increased the burden of contributing.
Instead, let’s create a gentoo-commits mailing list or RSS feed(s), with full diffs. We should use this tool in many different ways.
These uses will require that the commit diffs be easily filterable by both committer and files affected. RSS feeds could be made available based on developer or herd, and e-mail lists could contain the information in e-mail subjects or headers.
Second, we should improve our unit testing, where the units are individual packages. This can be both automated and performed by developers and arch testers. Although a number of packages have a useful, working test suite, most lack one. For these packages, we should attempt to provide something automatable in src_test() even when a test suite is absent. Failing that, we should print out a checklist in src_test() of tests to perform before stabilizing a package. There should never be an empty src_test().
Another package-level testing approach is to create solid, automated tinderboxes. This remains unrealistic for our entire database of 10,000+ packages, but we should at least get this going for our “system” set and perhaps for some of the most common sets of packages for servers and desktops. Exactly how to set this up remains a question, since there’s a lot of tinderbox code floating around. Bonsaikitten has some almost-working code based on swegener’s work; Catalyst has some tinderboxing capability; or we could look into using Mozilla’s tinderbox.
Third, we should improve our integration testing, on the entire repository level. Our main source of testing here will be our users, because they have infinitely more combinations of build options and hardware than we can reproduce on Gentoo infrastructure. But how can we take advantage of this testing to improve our quality? By creating an additional, time-lagged set of rsync mirrors with additional QA checks, we could allow users who want to test the latest and greatest software to help those who want stable and solid software.
We already have keywords for ~arch and arch, but they’re still too mixed. A problem in ~arch ebuilds can break the entire tree for all users. They really need a stronger separation. Perhaps the separate repositories should be ~arch versus stable. But another way to do it is to add a delay to the second set of repos, anywhere from 24 hours to a week. This delay allows us time to encounter major problems in the fast-sync repos, fix them, and carry the fixes over to the slow-sync repo. But we’ll need a way to make this really easy to do. It feels like branching with periodic merges, along with cherry picks of major bugfixes, is the right way to do this. Unfortunately, CVS sucks at this. We may need to migrate to a more capable version-control system before this option becomes realistic. In addition to the user testing, we could add a tinderbox into the slow-sync repos to require that they build with the most common configurations.
To sum up, I want to increase code review, unit testing, and integration testing. These three things will strengthen Gentoo’s quality, reputation, and community.
Reading the PressThink blog, I came across a couple quotes that apply well to open-source projects:
I kept thinking about a famous passage from Christopher Lasch, the great social critic and historian who died in 1994— before the rise of the Web. In the Revolt of the Elites, he said we learn more from argument than from information, not because opinions are weighter than facts, but because to argue for your ideas (in public) puts those ideas at risk. And that is how we learn. …
Lasch in his book:
If we insist on argument as the essence of education, we will defend democracy not as the most efficient but as the most educational form of government, one that extends the circle of debate as widely as possible and thus forces all citizens to articulate their views, to put their views at risk, and to cultivate the virtues of eloquence, clarity of thought and expression, and sound judgment… small communities are the classic locus of democracy— not because they are “self-contained,” however, but simply because they allow everyone to take part in public debates. Instead of dismissing direct democracy is irrelevant to modern conditions, we need to re-create it on a large scale.
Striving for greatness 