g2boojum's Gentoo weblog

Thanks to ferringb's blog post, I just finished reading the page on the Sourcemage wiki that describes the differences between Sourcemage and Gentoo. It certainly makes for interesting reading. I opened a bug 1184 almost exactly three years ago suggesting that we should implement some of the better ideas from Sorcerer Linux, some of which are still lacking in portage. It's quite clear that Sorcerer and its decendants have some quite good ideas. It seems a shame that the Sourcemage Gentoo diffs page seems to be a bit biased, since I would be very interested in an objective comparison of the distros.

Yes, I definitely overreacted to obz's post. Mike, I apologize profusely.

We're due to have a real discussion about GLEPs. I'll get it started on the -dev mailing list shortly.

In a recent post it was stated that GLEPs are "an arduous task, a pain to write, and relied heavily on the submitter to push the enhancement through". I've been hearing many similar complaints recently. I'm not quite sure I understand why they seem to evoke such vitriol, though. I'll admit that it does take a bit of time to figure out how links work in restructured text, but otherwise restructured text is pretty similar to how one generally does markup in a text document, so I'm not sure what makes them so hard to write. I'd be willing to accept generic text files, though, if restructured text is too complicated. Is it the structure of the document, breaking the GLEP into specific sections, that provokes ire?

The rationale behind the GLEP concept was that writing a GLEP should be an effort. It shouldn't be hard, but it should require thought. The idea was that the process of writing the GLEP would force the author making the proposal to assemble a well-reasoned argument for what should be changed and how it can happen. A well-reasoned GLEP is much easier for people to pick apart, find the holes in it, and improve it, than is a general thought thrown out on a mailing list.

Once written, the process is straightforward. The GLEP is submitted to the GLEP editors, who generally accept it and post it on the web site in reasonably short order. The author is then responsible for soliciting feedback, modifying it, and deciding when it should be sent up for approval. Once sent up for approval, either the related project manager makes a decision on whether to approve it, or, if it crosses projects, it is voted upon by all of the managers at a managers' meeting. That part, in my opinion, is the most arduous, but it's rare that a GLEP is ever rejected outright. Unsurprisingly, it may happen that people "agree with the idea, but not with the specifics". Hopefully a reasonable compromise has been reached before requesting it be approved, but sometimes the compromise has to come afterwards. My suspicion, though, is that in general the compromises made lead to improved proposals.

After a GLEP is approved, it is then up to the GLEP author to implement it. It's not uncommon for GLEPs to linger here, since implementation is often hard. My personal opinion is that a good idea without an implementation is still a useful thing, since at least there's a record of the idea, and somebody else might come along later to implement it.

Is it a bad thing that the GLEP editors do not nag GLEP authors about their GLEPs, to keep the process moving forward? I pushed to have a deadline for GLEPs to become inactive (and I'm about due to run through the list again), but my feeling is that if the GLEP author, somebody who was motivated enough to write the GLEP in the first place, cannot remain motivated, then nagging is unlikely to change much. The odds are good that if the GLEP is stalled, there is a reason. Either we lack the infrastructure to implement it, or not enough people are interested enough to invest their time and effort. That's not a "backlog" of GLEPs, it's just a list of GLEPs whose ideas aren't quite good enough, or at least not needed enough right now.

We're overdue for a managers' meeting, so I've scheduled one for this coming Monday at 1800 UTC. A managers' meeting is barely newsworthy, but this time around I'm stirring the pot a fair amount, and making the focus of the meeting the current Gentoo management structure. In my opinion the current structure suffers from three significant problems: (1) managers were appointed to indefinite terms, so Gentoo appears to be run by a "cabal" that has no accountability, (2) the current top-level projects (and associated managers) don't really "span" Gentoo very efficiently, and hence large numbers of Gentoo devs cannot easily locate the most relevant manager to him or her, and (3) the top-level project managers are supposed to collectively handle cross-project issues and provide a strategic vision for Gentoo, but it's not clear that the latter is occurring. Don't get me wrong, I actually do prefer the current system to the benevolent dictator model that we had previously, but we did lose something when drobbins stopped providing a single, strongly-held vision for the distribution.

So far my e-mail to -core announcing this meeting and its topic has produced few fireworks, or even much interest at all on the -core mailing list. On the other hand, I've had several folks drop by on irc and mention that my e-mail was "interesting". Most of these folks have been younger devs, so I wonder if the older, more jaded folks are just ignoring it. We'll find out, I suppose, on Monday. It should be interesting!

[Note: It seems that similar issues arose at FOSDEM, which I hadn't known about when I originally sent out my e-mail. I'm rather looking forward to seeing their new proposal.]