Tue, 01 Feb 2005
Releasing Debian
Yes, I know there's a wiki entry about that subject, but I happen to think wikis are a horrible way to discuss stuff. I don't like them. If someone thinks what I say makes sense and is interested in adding this (or a synthesis thereof) to the wiki, be my guest.
I've been thinking a while about why we can't seem to be able to release within a reasonable time. What exactly is "a reasonable time" is, of course, open for discussion; but the time it takes us right now is way more than "reasonable". My take is that to find out what we should do better, we should have a look at our history and try to find out what's going wrong. From there, we should try and find solutions to those problems. We should also not be blind to the world around us: there are other Free Software-projects comparable to our own (the BSD's and Gentoo, but in a way also KDE and Gnome, although those are different) that do seem able to release; it would be healthy to compare their release processes with our own and try to find out where we could improve ours.
I have come up with the following:
- Lazyness
- When the release has happened, we are happy. We have a party, congratulate ourselves for finally doing it, and then sit back and lazily wait what happens. It takes quite a while before someone gets up and say "it's time for us to release again; let's freeze base".
Unfortunately, this means that in the time between releases, people aren't focused on the actual release; if you ask a random Debian Developer about where we are in the release at any given point in time between the release of the then-current stable and the freeze of the next stable, it's very likely they'll tell you "I dunno". I know that was the case for me after potato's release and after woody's. - Time bombs
- Right when woody was about to be released, the security team yelled "whoa there, we can't support woody with this security infrastructure!" As a result, the release was delayed quite dramatically. Something similar has now happened to the sarge release. There's a pattern there. One could say the pattern is that we need to ensure that the security infrastructure is up to date before we release; but the real problem here is insufficient planning. When the release is near, people will find out that we're not ready, and the bomb will blow; at that time, the release will have to wait, no matter what— we can't release with the problem unfixed.
Of course, nobody can be expected to know about every possible and impossible problem before it happens; but people working on a particular task within the project will know if there are any problems that need to be adressed before the next release. They might just not know how close the release really is, and therefore do not communicate it to others... until it is almost too late. It has been the security infrastructure two times in a row now; but if we focus on not letting this happen to the security infrastructure for the next release, I fear it'll just be something else. Volatile not being integrated into Debian proper, for example. Whatever; it could be anything. - The sheer size of the project
- The Debian Project started off like many Open Source-projects do: a few enthousiasts thought it was a good idea to do a distribution, so they did one. When there was a problem, they would talk to eachother or just simply fix it; and when the release was near, everyone would know.
Today, the Project has grown way beyond that original group, with over 1000 individuals having the status of Debian Developer. We could easily fill all but the largest movie halls, opera houses, or stage theaters; if we would celebrate one Debian Developer each day, it would require us about three years to reach the last one of them. 1000 People is the size of a small village. As a result, it's nearly impossible to know each of those 1000 individuals personally. And if we can't know everyone, we certainly can't know what they're working on.
... In other words, I think it all boils down to one important thing: communication. If there are clear channels as to how something must be communicated, those channels are usually used properly. But what we lack is the big picture; someone to manage all the available information about what's needed to release, and communicate that to the Developer body at large. A way for each and every one of us to better understand our role within the scheme of the Release. Act on problems if there are any. This is the Release Managers' job, you'd say, and I agree; but I feel that for some reason that isn't working out as it should1. The fact that there have been time bombs is one prove of this.
This brings me to what I think is the heart of the problem: People in Debian are working way too much separately, and aren't talking to eachother enough. If we have a look at the Gentoo project, we'll see that they have identified some teams within their developer body, who work closely together; they all define a team leader of sorts, and the team leaders have weekly IRC meetings to discuss problems and plan ahead. There's a documentation team, a base team, a desktop team, a Portage team, etc; this ensures problems are dealt with before they're going to be a problem.
I'm not sure applying that to Debian is a good idea, though; I don't want a hierarchical structure where there are leaders and followers. Besides, I don't think our constitution would allow it. Thus, we'll need something else.
Looking at the FreeBSD project, we can see that they send periodical status updates to their announcements mailinglist. We have something similar in our Release Updates, but there are two differences: first, our Release Updates are only being sent when a Release is supposed to be near; second, the Release Update is created by the Release Managers, who will obviously only talk about the things they know about. In contrast, the FreeBSD status updates are sent regardless of whether a release is near; and they are composed after a request for status updates that is sent to their developers. In other words, every FreeBSD developer can write a section for the status update.
I'm thinking it might be a good idea to try this once Sarge is out the door; if people are working on something big, something important, they should have a way to inform the Developer body about the fact that they are doing so. Using -devel-announce could be a way to do that, but people don't usually make announcements about stuff that isn't ready yet; and if we would do so, then -devel-announce would no longer be the low-traffic list it is supposed to be. Grouping status updates into one mail would be reasonable to keep developers updated and informed on what needs to be done before we can release and how much of it has been done already, without annoying the hell out of people by sending them mail every other day.
But will this be enough? I'm not sure.
One thing that seems also quite problematic is that the Release Managers aren't always as informed about the release themselves, either. I was stunned to learn around last september that about a month had passed without a release, and that even the Release Managers didn't know what we were waiting for. I think we should all agree that the Release Managers will need to know at all time what's going on to be able to properly do their job; and that they may have reasons to ask other people that they do something in a particular way, even if that is against their procedure -- for instance, Release Managers might have a reason to request ftpmasters that NEW-processing for some package is done as soon as possible, or that the build of some other package on some architecture is prioritized over other packages; all so that the release won't be delayed. Currently, Release Managers can (and do) ask this of other developers, but if those other developers decide that they're too lazy or that they disagree with the Release Manager's decision, they will simply not do it; and there's nothing the Release Manager can do about that.
Of course I'm not pointing any fingers, nor am I advocating that the Release Managers be given some extra powers that would allow them to overrule any developer's decision without paying any attention to that developer's wishes; I do think, however, that they should have the ability to do what's necessary to make the release happen; and that might require more than just the ability to edit britney's hints, or politely ask other developers to please do something for them.
Whoa, this post ended up way beyond what I intended it to be. Let's keep it at that; in summary, I think the best course of action would be to
- Not stop doing release updates after sarge is out the door,
- Allow people beyond the Release Managers the ability to get something in the release updates, so that subprojects the Release Managers aren't familiar with can be more easily made public, too. This might include stuff that isn't necessarily important for the release,
- And finally, to give the Release Managers more powers. They don't need to become the Project Managers, but they should have the ability to say 'I want you to do foo, because the release is waiting for it' without being frowned upon
Of course, that might not make any sense, be stupid, or things might already be (partially) done that way. I dunno, I'm not a Release Manager...
1That's not to say that the Release Managers aren't doing their job right, of course; please read on
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|