Bits from the Debian Project Leader February 4

From:		Andreas Tille <tille-AT-debian.org>
To:		Debian Developers <debian-devel-announce-AT-lists.debian.org>
Subject:		Bits from the DPL
Date:		Wed, 04 Feb 2026 18:38:07 +0100
Message-ID:		<aYOD_-Hqq_nXUe1G@an3as.eu>
Archive-link:		Article

Dear Debian community, This is bits from the DPL for January. 1. Changes around FTP / DFSG structures 2. When stepping back goes unspoken 2.1. MIA team 2.2. Keeping Packages Approachable 2.3. Delegates 3. FOSDEM TL;DR: An update on FTP/DFSG changes, followed by a reflection on handling changes in contributor availability across Debian, including possible implementation work around the MIA team, and a brief FOSDEM note. 1. Changes around FTP / DFSG structures ======================================= In the past weeks we have discussed changes to the organisation of FTP/NEW and DFSG tasks. I would like to briefly explain the background, without reinforcing an "old versus new" narrative. Related concerns and reflections from the Community Team have been shared in a recent announcement[c01], which provides additional context on how these changes are perceived more broadly within the project. Over an extended period of time it became clear that essential work in this area was carried by very few people. This affected day-to-day processing as well as transparency, predictability and communication. Situations like this are unfortunately not uncommon in Debian and can arise not from bad faith, but from long-grown structures, increasing workload and limited opportunities to address problems early. Ahead of the recent changes, starting in my first DPL term I made several attempts to engage with the relevant delegates and to solicit feedback. These efforts did not lead to sufficient shared understanding to develop a sustainable path forward. Under these circumstances, organisational decisions were necessary to ensure continued functionality in an area that is foundational to Debian. I want to stress that this reorganisation is not a judgement of the work or commitment of individuals. Much of what works today is the result of years of dedicated effort, often under difficult conditions. At the same time, as a project we need structures that distribute responsibility sustainably and support transparency, collaboration and renewal. The new team has already started its work. Its focus is now on stabilising processes, improving communication and building trust. A short note on the transition period: following the delegation of the new DFSG team, access to the NEW queue and related operational details was not immediately available. This made it difficult for the team to carry out hands-on training and to prepare workflows ahead of taking on their responsibilities. While the upcoming delegation had been announced several weeks in advance, some of the necessary technical and procedural handover steps could only be completed later. As a result, the new team was not able to start working at full capacity from day one. This requires time, calm and support from the wider community. I therefore ask everyone to view the current situation not as "old versus new", but as a necessary step towards a Debian that remains reliable, open about challenges and mindful of the people doing the work. Remark regarding the Archive team --------------------------------- I would like to explicitly thank Ansgar for the work he did on the SQLAlchemy transition of DAK and its upgrade of the hosts maintained by the archive operations team to Trixie. This was important work for the project, and I very much appreciate that he took care of it. [c01] https://lists.debian.org/debian-devel-announce/2026/01/ms... 2. When stepping back goes unspoken =================================== The following thoughts are not specific to the recent changes around FTPmaster or DFSG, but reflect a more general pattern I have observed across different areas of Debian over time. During my time as DPL, an earlier gut feeling has gradually turned into a clearer observation: Debian has a structural challenge that is easy to overlook precisely because we are a volunteer project. Debian exists because people freely choose to spend their time on it. That is something I deeply value, and it is a large part of why Debian works as well as it does. At the same time, most of us joined with enthusiasm, not with an explicit agreement to later announce when our available time, energy, or interests change. Life circumstances shift, priorities evolve, interests fade - all of this is normal and entirely legitimate. What we largely lack, however, are lightweight and reliable ways to communicate those changes to each other. For many volunteers, being asked directly whether they are still active or whether others can rely on their work can feel uncomfortable - especially when the question comes from a friend or colleague. Out of consideration for each other, we often avoid asking. Out of the same consideration, we also avoid proactively stating that we have stepped back. As a result, responsibilities can quietly drift rather than being consciously handed over or concluded. This dynamic creates a kind of implicit protection for contributors, which is understandable and well-intentioned. At the same time, it can have real consequences for the project: bugs remain unattended, security-relevant accounts are left without active oversight, or delegated roles continue to exist on paper without clear current ownership. This is not about questioning anyone's commitment or goodwill. It is about recognising that, in a long-running volunteer project, availability changes - and that Debian currently has few established ways to make those changes visible in a timely and low-pressure manner. Over time, this has led me to think about how Debian could handle such changes in availability more consciously and more consistently. Rather than treating each situation as an isolated case, I believe it is useful to look at a few recurring areas where this dynamic becomes particularly visible, and where clearer structures could help both contributors and the project as a whole. In the following sections, I will outline some thoughts around the MIA team, delegated roles, and situations where package maintenance lingers with unclear status because availability has changed without a clear handover. 2.1. MIA team ------------- Following up on what I wrote in my previous Bits[m01], I would like to return to the topic of the MIA team and be a bit more explicit about the current state. While the discussion at DebConf and the ideas developed there were encouraging[m02], there has been no visible progress since then, and I have not received further updates in response to my follow-up questions. This makes it difficult for the wider project to understand where things stand and how to help move this work forward. As documented in the DebConf meeting minutes, the MIA team discussed a concrete and structured proposal for handling inactive accounts. For clarity, I am reproducing the proposed process below unchanged, as it represents the team's own work and intentions[m03]: The proposed process will be as follows: 1. an initial heuristic will be defined to identify possibly inactive contributors, which will be regularly reviewed for improvements 2. after a period of 6 months without activity, an automated system will email the individuals found once a month, with easy options to confirm their active presence, go emeritus, or contact the MIA team for clarifications 3. in case of no answer, an attempt to get a response will be repeated monthly for 6 months 4. in case of no answer, the MIA team will make one manual attempt to reach the person, indicating that failing to get a response on that, the person's packages (if any) will be orphaned 5. in case of no answer to that, too, after a month: 5.1. the packages will be orphaned 5.2. a last-resort attempt is made on debian-private to see if anyone can help reaching the person 6. if there is still no answer after this, the account will be referred to DAM for potential removal From a project-wide perspective, it is currently unclear how much of this proposal has already been implemented, which parts remain conceptual, and where additional help would be most useful. Regardless of the current level of continuity or resourcing, this proposal provides a concrete and thought-through basis that the project can build upon. Making the current state visible would help identify what exists already and where contributors willing to take this work forward could start most effectively. Given the importance of MIA work for project continuity, account security, and fairness towards contributors whose availability has changed, this is an area where Debian as a whole benefits from shared responsibility. The goal here is not to assign blame, but to encourage progress and explicitly invite contributors to engage constructively, even if that means rebuilding structures based on the work already done. Clearer handling of inactivity at the account level also has practical downstream effects, for example by making it easier to determine when package maintenance should be considered unassigned rather than merely silent. Finally, the process for getting involved in the MIA team itself is now documented on the Debian wiki[m04]. This includes information on how contributors can assist with MIA work and how membership of the mia@qa.debian.org alias is handled. Making this information explicit is an important step toward lowering the barrier for participation, and I would like to encourage interested contributors, particularly those who want to help implement and carry this work forward, to take a look and get involved. [m01] https://lists.debian.org/debian-devel-announce/2026/01/ms... [m02] https://salsa.debian.org/debconf-team/public/data/dc25/-/... [m03] https://salsa.debian.org/debconf-team/public/data/dc25/-/... [m04] https://wiki.debian.org/Teams/MIA 2.2. Keeping Packages Approachable ---------------------------------- The challenge is not inactivity itself, but situations where useful work becomes difficult or impossible because the only clear ownership indicator points to someone who is no longer responding. While the MIA team focuses on inactivity at the account and project level, this section looks at how similar dynamics affect day-to-day package collaboration. Over time, this silence creates uncertainty: contributors hesitate to step in, repeated NMUs become socially uncomfortable, and packages drift without a clear path forward. Over the past 1.5 years, including work on the Bug of the Day initiative, I have migrated a large number of long-inactive packages to Salsa - in practice, roughly one per day. Where maintainers were still active, responses were usually constructive or explicitly positive. Where packages had seen no activity for many years, the most common outcome was no response at all. For packages untouched for five years or more, this silence is itself a project risk: it leaves no obvious, low-friction way for others to help, even when there is willingness and technical ability to do so. This is precisely where shared, well-known workflows matter most. In my experience, having packages on Salsa significantly lowers the barrier for contributors: it provides a visible place to collaborate, a straightforward way to propose changes, and a clear signal that help is welcome. Using Salsa in such cases is not about forcing active maintainers to change tools they are comfortable with, nor about redefining ownership; it is a practical measure to ensure that long-term inactivity does not turn into a dead end for collaboration. At the same time, our existing processes leave a gap when a package is clearly being kept functional by others without an intention or ability to take over full maintainership. NMUs are explicitly temporary, yet a series of NMUs over an extended period is strong evidence that the listed maintainer is no longer providing active maintenance. Conversely, the "Intend to Salvage" process requires a level of long-term commitment that is not always appropriate or necessary. What we currently lack is a lightweight, neutral way to make the unmaintained status of a package explicit, without assigning blame and without requiring someone to immediately step up as the new maintainer. These concerns are not new. Variants of this problem have been discussed repeatedly on mailing lists and in BoF sessions, including at the last DebConf, but so far without leading to a concrete, project-wide change. One lesson from this may be that further discussion alone is unlikely to be sufficient without either a more structured proposal, or a clearer shared conclusion about where the project intentionally wants to draw boundaries. It is also important to acknowledge that not all contributors experience these situations in the same way. There are maintainers who do excellent and valuable work precisely because responsibilities are clearly scoped and collaboration boundaries are well defined. For some, the ability to work independently, without ongoing social negotiation, is not a shortcoming but a strength. Debian should continue to be a place where such working styles are respected and appreciated, as long as they remain clearly distinguishable from situations where a maintainer has effectively become unavailable without that being visible to others. This also complements the work discussed in the MIA section above: making inactivity visible earlier at the package level can reduce the need for later, more disruptive interventions at the account level. Examples of such signals could include maintainers not having uploaded a package for several stable releases, combined with the package being kept functional primarily through a series of consecutive NMUs. Making these situations more explicit would not be about forcing takeovers or assigning blame, but about providing a shared understanding that a package may benefit from clearer status or a more open maintenance model. Keeping packages approachable means making it clear - socially and technically - that help is welcome when it is needed. My view is that improving our shared workflows, particularly for long-inactive packages, is an essential part of ensuring that absence does not block progress. The goal of such work would not be to mandate a single preferred way of maintaining packages, but to improve clarity around availability. Debian should continue to be a place where maintainers can work independently and with clear boundaries, while also ensuring that sustained availability is visible and that prolonged silence does not leave contributors uncertain how to proceed. Greater clarity in this area would help both maintainers and contributors act with confidence. I would therefore welcome contributors willing to help turn these ideas into something more concrete - for example by drafting a proposal, collecting and summarising previous discussions (including BoF at DebConf25[p01] and mailing list threads[p02]), exploring whether a General Resolution or another mechanism would be appropriate, or helping to define a lightweight workflow the project could agree on. [p01] https://salsa.debian.org/debconf-team/public/data/dc25/-/... [p02] https://lists.debian.org/debian-devel/2024/12/msg00101.html 2.3. Delegates -------------- In some internal discussion people have raised the question of how Debian should deal with delegates becoming inactive, and how to do so in a way that is both effective and non-confrontational. I have read multiple thoughtful suggestions that converge on a common theme: we should normalize renewal and rotation, rather than treating changes as exceptional or adversarial events. All quotations below are used with explicit permission from the respective authors. Andrew Lee suggested a lightweight renewal mechanism initiated by the delegate: Delegates should send a short report with renew approval request to DPL six months before expiry ... It expires in time if individual delegate lost interests and doesn't send the request. The key strength of this approach is that it shifts the dynamic away from "dismissal" and toward self-reflection and explicit continuation. As Andrew puts it, this ensures that: The DPL knows the status of the delegation and doesn't simply miss a renewal window. Russ Allbery highlighted an important human aspect of this idea: This feels very lightweight, but it also pushes delegates to think "okay, do I really want to be a delegate, am I really doing the work, am I going to step it up or here's a nice graceful way to step down." This framing is particularly compelling: inactivity is not treated as failure or conflict, but as a natural point to reassess volunteer time and energy - something many of us struggle with. Stefano Zacchiroli approached the same problem from a structural angle, pointing out that the current model makes change unnecessarily confrontational: "Dismissing" a delegate is currently a highly confrontational process, where the burden of proof is on the DPL. He contrasts this with the Secretary role, where expiration is automatic, and reappointment is the explicit act: Reappointing the same person requires an explicit act of the DPL; compare this with delegates, where the DPL needs an explicit act to dismiss them. Zack's core proposal is therefore that delegations should automatically expire after a fixed time, with reappointment being the normal case when things are working well: I think such a mechanism would go a long way to de-escalate and de-dramatize things. Importantly, he notes that this does not require a constitutional change, but could be adopted as a DPL practice. As a very personal note, I want to add that I value the fact that the DPL role is explicitly limited to one year. Had I known in advance that the changes I consider important would realistically require two years to carry through, I very likely would not have stood as a candidate at all. The clear time boundary was a key factor that made it possible for me to commit to the role in the first place. This experience has reinforced for me how important time-scoped responsibilities can be in a volunteer project. Knowing that a role is limited makes it easier to step into it, even when the work is demanding and emotionally taxing. In the same sense, I can imagine that some developers might be willing to take on a delegation precisely because it is for a defined period: "For a limited time span, I can do this." Across these different areas, the underlying question is the same: how Debian can make changes in availability visible without turning them into personal judgements. Clear signals help responsibility move, reduce friction, and make it easier for new contributors to step in where needed. 3. FOSDEM ========= While I am not a frequent visitor to FOSDEM, I thoroughly enjoyed the experience. I felt like I met half of the Debian Developers in attendance, and my only regret was missing the other half in the massive crowds pushing through the hallways or queuing at the food trucks. Despite the bustle, I managed to have some excellent conversations, got help from others to navigate both the venue and Brussels, enjoyed a wonderful Debian dinner, and engaged in valuable cross-distribution exchanges. In my first talk "Debian Med beyond COVID-19: how a Debian Blend gained momentum"[f01], I focused on the work I did before serving as DPL - work I am eager to pick up again once my term concludes. During my second talk "32 years of Debian: how a do-ocracy keeps evolving"[f02] I was struck by the turnout. The room was so crowded that people were standing or sitting on the floor, and unfortunately, many were left outside, unable to get in. For those who couldn't make it into the room - or those who couldn't attend FOSDEM at all - both talks were recorded. You can find the videos at the links provided above. [f01] https://fosdem.org/2026/schedule/event/AGQGYY-debian_med_... [f02] https://fosdem.org/2026/schedule/event/H3KFYZ-32_years_of... Kind regards Andreas.

Attachment: signature.asc (type=application/pgp-signature)