iTWire: What do you think about setting as firm release dates as possible?
|
|
However, in the end I've always been an advocate of the notion that we shouldn't release until we are ready to release. There has to be a balance here somewhere. I have seen other projects be reasonably successful at trying to stick to relatively firm schedules. On the other hand, I've seen lots of projects drive themselves to an incredible level of stress around release times because there are things they want to fix but they really want to release on a particular date.
There's always a balance - without deadlines, it's very easy to leave things and not have a sense of urgency about them. But, on the other hand, deadlines that are too rigid drive too much stress into the system, particular for volunteer activity. So we have to have a balance.
iTWire: Do you think it's a good idea to get moderately experienced users of Debian to use testing - tell them it's fine, you can use testing instead of always waiting for a stable release?
BG: Testing came about initially because I was having a conversation with some of the people who worked with me in the old HP many years ago about the system we had at that time, which was just stable and unstable. There were two problems - one, that many users didn't want to get stuck running something that was getting out of date, as stable always tends to be after it's released, and yet they didn't want to be subjected to all of the noisy breakages - some of which used to be really hideous, like /bin/shell not working after an upgrade - that would happen in unstable of that era.
People had this desire to have something that was in-between from an utility standpoint. But then there was this issue in the early days of Debian, the way we did a stable release was to take a snapshot of unstable and then work to try and close the gaps on it. The proposal that I made was that we think about the possibility of an intermediate step that would be subject to a set of mechanised rules to ensure that the worst breakages that showed up in unstable would not be there, and yet it would be as fresh as possible. It seemed to me that would give us a big step in the right direction towards being able to make a release.
Anthony Towns is actually the one who took up the idea and ran off and wrote a bunch of code and implemented it and his primary motivation was to implement the sort of rolling release candidate part of the proposal. I think he did an excellent job of it and that led to it being called testing and it led to the current situation where that is how we stage the future release.
But, somehow in that process, I think the idea that 'this is something that maybe the majority of our desktop end-users might want to run as their choice of distribution', that kind of got lost in the definition. I've always thought that the thing we now call testing is the thing that most end-users would probably like to run. But it does require extra work from people like the security teams and so forth in order to make its something with which everybody's comfortable.
At any given moment in time I've had different feelings about it. I certainly have arranged that most of the machines in my house that aren't mine end up running testing. My wife and kids are currently running Lenny (and have been) for a while. They'll probably keep running it for a while after Lenny releases stable but at some point there'll be some new application or feature they want that makes them roll forward to whatever the next testing distribution is.
CONTINUED
