Thursday, March 31, 2005

1 April 2005

Yes, it's 1 April. No, whatever you're reading probably isn't true.


Monday, March 14, 2005

Differences between Sourcemage and Gentoo

Thanks to ferringb's blog post
(http://dev.gentoo.org/~ferringb/blog/archives/2005-03.html#e2005-03-14T18_03_31.txt"),
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
("http://bugs.gentoo.org/show_bug.cgi?id=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.


Thursday, March 10, 2005

GLEP overreaction

Yes, I definitely overreacted
to obz's
(http://dev.gentoo.org/~obz/blog/archives/2005-03-11T00_32_59.html)
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.


Wednesday, March 09, 2005

GLEP thoughts

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.


Wednesday, March 02, 2005

Upcoming managers' meeting

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.]


Contributors

Label Cloud