Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen.
You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions.
He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam.
Who are you?
I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf.
As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian.
Can you describe your journey in Debian and in the release team?
I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels.
When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9.
As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say
How much time do you usually spend working for the release team ?
I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer.
During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time .
What s your own retrospective of the Squeeze release? What went well and what needs to be improved?
Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle.
One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS s blocking functionality to indicate reasons why a request cannot be fulfilled right now.
Are you in favor of time based freeze?
I think there s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package.
One thing I m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about.
What are your plans for Debian Wheezy?
The Wheezy to-do list I started before the final Squeeze release begins multiarch, multiarch, multiarch . It looks like we re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so
and more transparent.
With my package maintenance hats on, I d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian.
Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing stable can be accommodated to support this?
I m not yet convinced that the concept of a rolling, constantly usable distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The testing distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions.
It s been suggested that testing and rolling could be basically the same for most of the cycle, with rolling then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that testing was intended to avoid (i.e. the old frozen suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time.
What s the biggest problem of Debian?
The thing that I ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves.
That s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a do-ocracy then we need to permit people the freedom to do .
Is there someone in Debian that you admire for their contributions?
All previous release managers, for making the job look much easier than it seems when you re in the hot seat .
Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.
Thank you to Adam for the time spent answering my questions. I hope you enjoyed reading his answers as I did.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on
Identi.ca,
Twitter and
Facebook.
No comment Liked this article? Click here. My blog is Flattr-enabled.
Well, I still don t feel ready enough to go back to (real) work. So, once more, I had to get my fingers on something to hack and I picked the Buildd Status Pages once more. It s not my favorite project, but I decided to implement the few remaining ideas and get (temporarily) done with it. So, here we are with new features (and a few bug fixes):
At least, it was very easy to fix.
On next Monday this cycle s 
); only a very small fraction of it (where I explain package names, etc.) will be specific to Debian/Ubuntu, but shouldn t be hard to apply to other distributions as well.
So please feel invited to join, and bombard us with questions!
It's incredible how many people are of the misguided belief that just
because I happen to 
Whenever I develop a little command line tool, I end up writing
some boilerplate code. For example:
I just received a strange call. Basically, someone phoned me up and tried to convince me to change my computer s settings. They called my direct line (not the co-op switchboard), so I think they might be calling other numbers in the Weston-super-Mare area. Watch out for this attack.
I d heard about these calls from 
The Background
If you weren't online last Friday you probably have missed the big news announcement on the 
Alright. If you ever come into the same situation I was in and need a newer kernel (2.6.32 or up, perhaps also 2.6.31) on some system with old iptables package (versions below 1.4.0 I think, 1.3.5 in my case: CentOS5/RHEL5), you might get this helpful error message when using the iprange module in your iptables rules:
After todays or yesterdays daily package update (Sid) several kernel modules, namely