DPL Platform 2019

I am a Debian Developer since 17 years now, having joined Debian in April 2002. Real life people think I am THE ANSWER since mid march, having turned 42 recently. I live right in the middle of Germany, in the nice medium sized town named Fulda.

I manned various booth for Debian at a number of events over the years. There have been multiple LinuxTag, LinuxWorldExpos and Cebits as well as Chemnitzer LinuxTag, FrosCon and other smaller ones. Sometimes I just appeared, sometimes I handled the complete orga needed for it, including creating Debian CD/DVDs to hand out to visitors as well as organising merchandise. During the first such event I found (or rather, the upstream author of it found me) my first package to maintain.

I have been an application manager for the NM process since shortly after I became DD and became Debian account manager assistant in 2004, full DAM in April 2008.

In March 2005 I joined the FTP team as an assistant and became FTP Master in April 2008.

After DebConf5 i joined the the DebConf orga with my main role being admin of the infrastructure, as back then it was separate to Debian. Beside the admin stuff I helped with or lead various other teams, say content or travel sponsorship.

I am part of the mirroradmin group, having written the base of the current master sync scriptset for the mirrors.

I am one of the admins for our Debian Planet and am one of the admins for Debian's gitlab service salsa.debian.org.

I am also a staff (NOC) member at OFTC, the IRC network where irc.debian.org points too.

Between August 2007 and February 2018 I have been a board member of SPI, Software in the Public Interest, with most of the time being VicePresident and main administrator. SPI is the legal umbrella that Debian sits in within the United States, and holds the majority of Debian's assets.

It's this time of the year again. Many line up, ready to fire questions on the -vote list, with only five lined up to answer. It's DPL election time, long threads to surface at the list. Everyone wants to know how the next leader is going to lead us into the gloryful future of the universal OS.

How to overcome all the challenges a distribution like ours faces, how to adapt to the ever faster changing world?

How to become more attractive for all the commercial entities that are currently chosing to ignore Debian but select a derivative?

How to become more attractive for developers?

How to renew our tools to some more modern workflow? A common wish being to modernize the BTS (web interface anyone?). Or uploads with a git push.

How to be more diverse? (Look at this years nominees…)

How to make large-scale changes in Debian simpler?

How to deal with the "curl | sudo bash" mentality of newer languages and their environment? How to, usefully, include those languages?

And I am sure, many many more.

I am not really good in predicting the future, but one thing I am willing to put a bet on is that Debian will continue to be relevant for the community. We have many users, directly or indirectly via derivatives. They continue to need a stable, predictable and simply working system, which we are good at delivering.

We should not relax and accept just being a building ground for others though, we should look why people chose something different than Debian. And see if we can enhance Debian to provide the features, while balancing it with our current users. And yes, that includes users that are building on top of us.

We need to ensure to cater to the millions of users we have. They range from those who want a really stable system and loath change to those that even find our unstable distribution to slow to change.

Thats not an impossible task, we have some of the most brilliant people working with the project. We are the experts in making sure our software integrates. And we need to make sure that we keep those properties. And extend them to the new challenges.

And some of those challenges are big. The current hypes on the current "perfect way of doing sysadmin/devops/…" are seldom based on full distributions.

As the DPL is not the lead of actual technical development, it is not for the DPL to find technical solutions for the challenges we face. Or to find the perfect answers to the series of questions (and all the others that are out there) I put above.

But the DPL ought to enable other project members to do so, and that is one major part I will focus on. Many of the above points are nothing that can be implemented in short terms like a year, but at least one can start on them. Some may already get worked on, then it is important to continue work and keep people engaged and motivated.

The DPL should work removing blockers and let developers get on with their jobs.

It's also the job of the DPL to listen. And be guided by the community.

Debian does not only consist of packaging and similar technical activities, we have a lot of other contributions that are equally important. We need to encourage more people who aren't well versed in the technical work to contribute in various non-technical ways. That can range from writing documentation, translations, help with the website, design work, help users with their problems or representing Debian at events. Or organizing such events, like Bug Squashing Parties or local "miniconf" gatherings. All of that is as important as the packagers work.

I will work with anyone who wants to improve processes within Debian to identify non-trivial bottlenecks, to reduce our complexity and to improve communication between teams, where needed.

I intend to continue the transparent ways from Chris (and other former DPLs) with regular activity reports, though my style naturally will be different.

Also, as we are a really big project, there will be areas where I simply not know enough (or anything) about. I'm not afraid asking for help.

The DPL job is one that takes a lot of time and energy. Having a fulltime job and a family with 2 kids does not make it easier. As such I discussed it with all involved and got full support for my nomination.

To be a bit more precise: My company calculates with a full 45 workdays that I spend on DPL duties (out of the approximately 250 workdays during a DPL term). Additionally to my usual vacation days.

The time I take will depend on the actual DPL tasks and can range from just hours a day to full absence when traveling to some event.

That is just what I take out of work time, the actual time I can spend on DPL duties will be higher, but I am not going to put up a definite number. It will adjust to what is needed, when it is needed.

Lets start with the most important one in this context, DAM. The constitution is simple there. $8.1.2 is specific for this. It says:

The Project Leader's Delegates:

[…]

may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader.

The simple takeaway here is that, should I get elected, I will resign from DAM.

Besides the above quote the constitution only forbids the secretary and the chair of the CTTE to be DPL, so I do not see any conflict with keeping my other delegation, FTPMaster. That is, until the moment I would need to update it, then I would need to resign from that, as a DPL may not delegate to themself.