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.



Does your remote support strategy keep you and your CEO awake at night?

Today’s remote support solutions offer much more than just remote control for PCs. Their functional footprint is expanding to include support for more devices and richer analytics for trend analysis and supervisor dashboards.

It is imperative that service executives acquaint themselves with the new features and capabilities being introduced by leading remote support platforms and find ways to leverage the capabilities beyond technical support.

Field services, education services, professional services, and managed services are all increasing adoption of these tools to boost productivity and avoid on-site visits.

Which product is easiest to deploy, has the best maintenance mode capabilities, the best mobile access and custom reporting, dynamic thresholds setting, and enhanced discovery capabilities?

To find out all you need to know about using remote support to improve your bottom line, download this FREE Whitepaper.


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.