Home opinion-and-analysis Open Sauce A conversation with Bdale Garbee

Author's Opinion

The views in this column are those of the author and do not necessarily reflect the views of iTWire.

Have your say and comment below.

iTWire: What do you think about setting as firm release dates as possible?

BG: I think it's advantageous for the people who build dependencies downstream of Debian releases to have an understanding of the project's intent. It's valuable when we can figure out how to stick reasonably close to schedules that we have communicated.

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.


WEBINAR 26/27th May

Thinking of deploying Business Intelligence (BI)? So are your competitors.

And the most important, fundamental, tool for delivering your BI information to your users? Dashboards.




VMware changed the rules about the server resources required to keep a database responding

It's now more difficult for DBAs to see interaction between the database and server resources

This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware

1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance

Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!


Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.






Join the iTWire Community and be part of the latest news, invites to exclusive events, whitepapers and educational materials and oppertunities.
Why do I want to receive this daily update?
  • The latest features from iTWire
  • Free whitepaper downloads
  • Industry opportunities