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/msg00010.html
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/msg00004.html
[m02] https://salsa.debian.org/debconf-team/public/data/dc25/-/raw/main/etherpad/txt/232-mia-team-interal-meeting.txt
[m03] https://salsa.debian.org/debconf-team/public/data/dc25/-/raw/main/etherpad/txt/232-mia-team-interal-meeting.txt#L30-50
[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/-/raw/main/etherpad/txt/2-dealing-with-dormant-packages-ensuring-debian.txt
[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_beyond_covid-19_how_a_debian_blend_gained_momentum/
[f02] https://fosdem.org/2026/schedule/event/H3KFYZ-32_years_of_debian_how_a_do-ocracy_keeps_evolving/
Kind regards
Andreas.
Attachment:
signature.asc
Description: PGP signature