More fun, more trust
Presentation
I am a molecular biologist, and I am contributing to Debian on my free time since 2005. I give most of my Debian time to the Debian Med project, where I package software related to bioinformatics. Debian is much about freedom, and I think that in an era where technology plays an ever-increasing role in healthcare, it is essential that everybody has a free and unbiased access to the tools to manage and understand their physical condition.
I maintain a large number of packages, and this lead me to propose or participate to several efforts to standardise and rationalise parts of the packaging workflow. In order to produce a free distribution, we have to carefully check what we distribute, and to ease this task, a machine-readable format was elaborated for the copyright and license summary of our source packages. I participated to the brainstorm in the Debian wiki, and did a large part of the simplification of this proposal that is now known as 'DEP-5'. I also experimented a peer-review system for the upload of new packages. Recently, I started to work on how to manage meta-data about upstream projects outside of the debian/control file in our source packages.
My feelings about Debian
What makes Debian unique
I think that Debian is more than one operating system, it is a community dedicated to bring together free programs and generously distribute it in a way that contributes to our societies. We are not the only community with such a goal; I think that what makes us different is that our project lives mostly from donations. From its contributors who donate their time, from sponsors who donate machines, facilities, and pay some of our developers to work on Debian, from users who donate their feedback. This in turn gives our project an unprecedented freedom of operation, which together with our high goals of software freedom and technical excellence makes us unique.
Debian is in growth crisis
Debian's growth is continuous, in terms of number of packages, supported platforms, contributors, and like in most other growing projects, be them for-profit or non-commercial, we have to be careful to not be victims of our success. I think that some of our problems and dissensions are symptoms of a growth crisis: the difficulty to accept new members, the painful releases, and our relative isolation (measured in our difficulty to adopt external standards and to get ours adopted when we innovate).
I think that the keywords to solve that problem are fun, trust, and coordination. Since we are all volunteers, fun is very important to keep motivation. Also, it is important for us to appreciate our own contribution to society: if is not the same to share something we had fun producing, compared with being under pressure to deliver a result in time. Trust and coordination are essential to keep each other's fun. We need more trust, peer-reviewing and resilience to errors, compared to checks, approvals and queues. In return, we need to actively report our progresses, check if they are consistent with other developments. What happens too often in Debian is situations where people just give up, and start to ignore each other.
Program
My main priorities as a DPL will be to help Debian to resolve its growth crisis.
Membership
Becoming a member gives motivation, responsibility and reward. Currently one has to prove a lot to become become a DD, and I think that the level we require for new members is nearly to be able to do distribution-wide quality control and participate release operations. While it is exactly that manpower that we are critically needing, I do not think that it is in the interest of the project to be so restrictive on membership. I liked a lot an earlier proposition that any DD can nominate a new member in the project. This resembles how the DM status is working, and it is working well. Importantly, to make it easier to enter the project also makes it easier to leave it for a while. With a more appealing emeritus system, we can give motivations to DDs who are lacking time to take a break officially instead of simply becoming inactive for a long interval. And if lost membership can be recovered more easily, I think that we can also ease the conditions for cancelling inactive memberships. I will restart discussions on membership, with a vote as a goal.
Less restricted operations
I think that membership is not the only area where any DD should be able to operate, under the eyes and possible veto of all other DDs, with delegates to resolve eventual disagreements. DDs should be trusted to do the right thing when dealing with their packages, and for instance should be able to change their section and priority, control their migration to testing, determine on which architectures it will be built, etc. Many of these actions are controlled by plain-text files in restricted places. I propose to make them writable by all DDs, with temporisation and public notifications systems that will catch errors.
Release architectures with support a coherent subset of packages.
With a couple of changes on our packaging system and architecture layout, we can introduce a lot of flexibility in what we release. I propose that we do not need to release all packages on all architectures. This will allow to release new architectures earlier, typically when they can provide a core system à la Unix, and will allow also to lower support for declining architectures step by step. Perhaps with such a system we still would have a m68k port? This will give more earlier reward, more fun and less stress to the people interested in non-mainstream architectures, and release pressure on the people maintaining software that is not supported upstream nor widespreadly used on these architectures as well.
Flexible release geometry : blending a stable core with backports and snapshots
Not building the packages on all architectures opens of course the question of the release criteria. I think that it is possible to redesign our section and priority system so that architectures can be released with a partial support of our archive. Actually, in my experience of maintainer and user, there are leaf packages for which I do not think that our users enjoy our release strategy: they do not expect security support for these leaf packages, and they either would like the latest version, or a specific one that is neither in stable nor unstable. With the arrival of official backports and snapshots, I think that we can evolve our release strategy to focus on the core of our package dependency graph.
What I will do as DPL
I think that the role of the Project Leader is to help the project go forward, by overcoming inertia and resolving conflicts. Our constitution gives him many tasks and it is through these tasks that I will make advance the main points of my platform, assuming that if I am elected there is a significant number of developers who are supporting the ideas I presented above.
Delegates: I will contact the current delegates, ask them about their involvement for this year, if they wish to be replaced, or if they need help. I will discuss with them of a more detailed description of their role, and renew the delegations under the agreed terms, or look for new delegates. I will publish all the new delegations in a dedicated page of our website.
Discussions: there are plenty of reasons why some important discussion stop without conclusion on our mailing lists. It is also important to make pauses to cool down, brainstorm, or simply get things done on other tasks. After such pauses, I will restart the discussions that match the key points I listed in my platform, or that have attracted enough constructive interest, and lead them to a conclusion.
GRs: Sometimes, lack of consensus and action does not reflect conflict or division, but simply that in a large project like Debian, which heavily relies on electronic communication, it can be difficult to get the feeling of approbation. In these cases, I think that a vote can be a very healthy process, and I will initiate GRs when the Project is blocked on choosing between directions that are all acceptable.
Money: I will focus our spendings on things that are difficult to obtain by donation, in particular shipment for hardware and transport for people. I will not use it to pay for software development. I will report every second month what I agreed with.
In addition to these constitutional roles, I will report on my other activities every other month.
What I will not do as DPL
Travel: I have a full-time job and live far from Europe and America. I will not have enough free time to attend meetings in other continents.
Interfere: As wanted by the constitution, I will not push my opinions or interfere with the approbation of new members (nor DMs).
IRC: I am clumsy on this medium, and live in a timezone where it is time to sleep where most other project members are active, so I will not be present on IRC on a regular basis. I can of course connect if there is a discussion to make.
More fun, more trust
What we do, we have to do it because we believe in, not because some computer settings are forcing us in one direction. In one year of DPL mandate, with delegate nominations, by leading discussions and concluding them with GRs if necessary, I would like to help the Debian project to open itself to new contributors, to make possible - and expected - that developers operate directly on our infrastructure instead of taking tickets, and therefore re-equilibrate the workload so that developers get an equal share of fun and housekeeping duties.
Rebuttals
Stefano Zacchiroli
I share Stefano's point of view on Debian's tendency to become an imperfect do-ocraty and his goals of increasing transparency for the DPL and his delegates. However I find his platform vague a couple of key issues. About DMs, if they should be members of the Debian project or not. About releases, for which he does not have a dedicated section in his impressive platform's index. I think that we have a strong point of disagreement there about the way Debian releases. The efforts that as a DD he makes to reduce RC bugs are impressive, but I think that it follows an unsustainable path as it cures a symptom, not a cause. Better QA and more team work will help of course, but I think that we need to change our strategy.
Wouter Verhelst
Wouter puts a strong emphasis on getting more members in Debian. I really appreciate that his platform addresses the problem of hostility on our mailing lists. But like for Stefano, he does not give the impression that he is willing to ask Debian to accept its new contributors (like the DMs) as members earlier than what we do now. His platform also does not mention the releases, except for suggesting that it our current model is preforming better than in the past.
Margarita Manterola
I like the spirit of Margarita's platform. Keywords like art, accomplishment, appreciation, shining light and fanning flames. But will it work if we keep enthusiastic contributors outside of the Project until they get a packaging black belt?