DPL Platform

Neil McGovern


Hi there,

For those who don't know me, after a long history of Debian in a number of different teams and roles, I'm again running for Debian Project Leader. Much of this platform is the same as last year, as I believe the issues have not yet been resolved which led to my candidacy last time.

Debian activities

Having done a lot of stuff in Debian, it's a bit hard to remember and list them all, but below is a brief overview of the wide-ranging areas I've been involved with.

I first started getting involved with Debian in 2003, by packaging a blogging client called 'Drivel'. At that point I applied for DD status, and after going through 3 AMs, finally got my account in 2005. Since then, I have been involved in a wide range of areas in Debian:

Release team / Release Manager
I suspect most people will know me from my time in the release team, and later as Release Manager for three releases in a row: Lenny, Squeeze and Wheezy.
Press officer
I'm currently one of the Debian Press Officers, dealing with the press enquiries that occasionally reach us, rather than going straight to the DPL.
Assistant secretary
Since 2008, I've served as an assistant to the then Secretary, Manoj, Bdale as acting secretary, and later to Kurt, helping set up GRs and providing views on the interpretation of the Constitution for their advice.
I first became involved with the DebConf organisation team in 2006 in Mexico, setting up the main DebConf Website, and then co-organising DebConf 7 in Edinburgh, UK. I stayed involved for DebConf 8 with the sponsorship team.
SPI board member, and secretary
I was first elected to the Software in the Public Interest board in 2006, and continued until 2009. SPI is the legal umbrella that Debian sits in within the United States, and holds the majority of Debian's assets.
Webapps-common policy group
I was one of the authors behind the attempt to get a common policy for packaging webapps in Debian. The draft was fairly complete at the time, but highlighted the differing needs of upstreams and Debian when it comes to packaging webapps, an issue that still continues today.
Google Summer of Code admin
For two seasons, I was an admin of the GSoC project in Debian, helping students be assigned mentors.
Application manager
Possibly due to the length of time it took me to get through NM, I was motivated to become an AM myself, so did so with a couple of applicants. At the time though, the workload was huge for an AM, and I'm glad to see it's improved massively.
Secure testing team
The secure testing team was set up to help provide some level of security support for Debian's testing suite. This involved tracking things through unstable, and the set up of the security tracker, as well as review of packages and issuing advisories for unembargoed issues.
Debian UK clothing
Finally, I designed a number of t-shirt designs which may be recognised by a number of people reading this, or just me in the Debian kilt!

Other activities

In my day job, I work for Collabora who are an open source software consultancy, based all around the world. I'm the Engineering Manager, making sure our great team of consultants are happy and working on projects they enjoy - contributing to open source software.

Dabbling in politics, I've been a city councillor for Cambridge City Council from 2008-2012, and I've also been on the board of the Open Rights Group, a UK-based organisation that works to preserve digital rights and freedoms by campaigning on digital rights issues. I'm also a member of the Network Operators Committee on OFTC, and a regular irc op on #debian related channels.

Debian - Our shared vision

Where we came from

The Debian project has been around for a long time. Early in our history, we found a simple concept: "the universal operating system". Over the last 20 years have shifted somewhat to what we are today. Some of our earliest traditions remain core to the project, and some have moved to better align ourselves with the wider free software community. This is not a bad thing - when we were first founded, the wider ecosystem didn't exist - Debian has help found and create that ecosystem. However, some key characteristics remain fundamental to the project:

A dedication to technical excellence
No matter what, Debian takes the technically correct decisions. We don't shirk away from this - we embrace it.
We are a community distribution
Debian is not, and shall never be controlled by a central figure or power. Our power comes from the very people who work on the project - those who dedicate the time and their skill to making Debian the best it can be.
We integrate
Through Debian Policy, our software works together. Through our diligence, we have upgrades rather than reinstalls. Through our expertise, Debian just works.
We care about software freedom
The Debian Free Software Guidelines are core to what we believe. They empower us to make the world a better place.
We care about our users
Without people using Debian, we have no purpose. There is no point in producing an academic operating system that cannot be used by real people, every day.

These core concepts have existed for many years. After all, there's a reason why Mike likes Debian.

Where we are now

37500 packages. 12 architectures. 3000 contributors. 144 derived distributions. Debian has never before been more important. But one must wonder - are we still serving our core aims? I answer with an emphatic yes.

We've had arguments and unrest over the init system debate, and even though there is a large strength of feeling over the right path to take, it's much calmer than in the past. It may not seem like it at the time, but there's been no expulsions, no DPL recall votes, no fundamental forks of Debian. I believe it's our technical excellence that helps us continue to work together.

As a community, we seek to work with each other. There remain issues on how exactly we can do this - the disparate needs of packagers and trying to ensure we move towards a common system that works for everyone is sometimes in conflict. One thing that we need to remember is that Debian is a volunteer project. People can't be forced to work on a particular aspect, and we rely on others to do the bits of producing a distribution that we ourselves don't like doing, or can't do alone.

Our releases are well tested, and integrate with each other. However, as Debian expands, this goal is becoming harder and harder to achieve. A lot of good work comes from those who take a broad view of Debian, and don't look at just their packages.

Our core teams are generally working well, but can attract criticism for attempts to do their job. They also lack volunteers, but finding people who are interested and have experience in those roles is difficult.

We have managed to successfully release approximately every 2 years for the past 4 releases, providing a platform for our users. For some, this is too slow. For others, it's just right. We've managed to set a timeline in place to give some visibility for when we're releasing next, and to enable contributors to know what's going on and what to expect, but there remains an issue about the time it takes in the freeze.

Where we are going

I'm terrible at future predictions, but one thing I'm willing to predict is that Debian will remain relevant to the community. We've moved from people using Debian directly to some of our derived distributions, but I'm not convinced that the raw numbers show a mass exodus away from Debian, instead it shows an influx of other people who have not used a free operating system before. This is something we now seem to have come to peace with, but that doesn't mean we should simply be a base distribution others can build off, and not be useful in our own right.

We need to ensure that we cater to our users, and there's millions of them. From those running the latest software in unstable, to people who simply want a rock solid core release we can put on our servers, receive security updates, and leave alone. The size of Debian is increasing, and will reach a point where we're unable to guarantee basic compatibility with other packages, or the length of time it takes to do so becomes exponentially longer, unless something changes.

Yet this is not something that is insurmountable, we have some of the brightest people in the world working with the project. We are the global experts at making sure our software integrates. We need to ensure we stay that way.

How I will help get us there

I will support and enable those who do the work to get what they need, when they need it. Compared with a number of years ago, our core teams are working well. I believe it is the DPL's job to remove the blockers and let our colleagues get on with their jobs. That's not to say they shouldn't get the support they need. I will listen to our contributors and users, and be guided by those who want Debian to go from strength to strength.

I will push for implementation of "PPA" archives, and modernising our build and infrastructure system by working with the FTP Masters, wanna-build team, and DSA. It should be much easier for us to produce a working system with the correct tools, and some of our core infrastructure has not been keeping up with what we need to make such a large system.

I will promote and encourage engagement in non-packaging aspects of Debian contribution. We need to reach out more to people who aren't involved with these teams, and encourage them as an important part of producing the distribution. One method to help achieve this is via a mechanism we've had for a while - mentoring, but applying it to non-packaging work. I'd like to see this embedded into all of our processes.

I will continue to communicate with the project - the daily DPL log as set up by Stefano is a great tool, and monthly bits mails are helpful to show the project what the DPL is up to. As far as possible, I will engage with teams and the project on public lists, as this is one of our fundamental priorities.

I will spend some money we have horded. Debian currently holds approximately £200,000 at SPI alone. Our donators didn't give us money for it to be sat around in a bank account, we should spend it to make the project more successful.

What else?

There are many more areas that the DPL could get involved with, and many more promises I could make. I think that doing so would be foolhardy, the job of the DPL is a tough one that requires a lot of work, and I don't want to bite off more than I can chew immediately.

The DPL has a unique role. If there's an issue which only the DPL can solve, I'll do whatever I can to ease the issue and find a resolution. Be it authorising new expenditure so that we get buildds that are reliable, or speaking to the press and industry about the benefits of Debian, or even simply encouraging all who want to help us in the project, as DPL I will ensure we let our colleagues get on with the work they love.



I've known and worked with Mehdi for a number of years on the release team, and he's done some sterling work, particularly around the transition tracker. If I was still release manager, I'd be sad to be losing him to the world of DPL-dom! However, as we've been asked to critique the platforms, I'll try and comment on some of the aspects he raises.

Process review/Roadmap
This is a nice idea, but I suspect it's somewhat larger a task than Mehdi realises. Speaking to Steve McIntyre about just the team survey, this took up most of his time for a year.
Change management
I disagree with Mehdi a bit here. It is important that changes and implementation details of the changes are considered, but I don't believe that the DPL is the right place for this to happen. We have delegates (in the form of policy team, release team, tech-ctte, etc) who's role it is to help consider these. If there's something missing which means that it's not happening, we should address that, but I don't view the role of the DPL as one which gets into that level of detail.
Recruitment/Adapting Debian/Approach/Time
I think we're mostly in agreement with each other here :)


I've not worked with Gergely as closely, but we've chatted a few times on IRC before. Having a look at his platform, it's quite light on content. It's not clear (to me at least) what having a year with Gergely would be like, but I'm sure it'd be a unique one :)