Dear Debian community,
This is bits from the DPL for November.
Future of the DFSG Team
=======================
Over the past weeks, there has been promising progress in the
development of the new DFSG team. New contributors are stepping
forward, learning the workflows, and taking on tasks that will
strengthen the long-term resilience of NEW processing. This fresh
activity is very welcome, and I am grateful to everyone who has
volunteered their time to move things forward.
At the same time, I want to acknowledge the extensive and often
demanding work done by the current team members over many years. My aim
is to support a handover that recognises their contributions while
ensuring that the newcomers can take on responsibilities with confidence
and autonomy.
Looking ahead, there is also an opportunity for the new DFSG team to
shape Debian's future in ways we may not yet fully anticipate. Beyond
addressing the immediate workload, fresh perspectives can open doors to
improvements and ideas that go beyond the purely operational -- and I
trust the new team to explore such possibilities as they grow into their
role.
I have sensed some urgent questions inside the community, so I will try
to address these here.
Questions & Answers
-------------------
Q1: Why is there a discussion about changing the way NEW processing works?
Over the past two years, I have heard clear feedback from the project
that the predictability and transparency of NEW processing needs
improvement. This is not primarily about the number of packages
processed, but about whether contributors can understand what to expect.
When a package remains in NEW for a week or a year, the reasons should
be traceable and visible to everyone.
Q2: What was the issue with transparency?
For many years, the internal workflow around NEW processing has been
hard for contributors to observe or understand. Debian relies on
transparent processes, shared expectations, and predictable behavior.
Many maintainers expressed frustration that the NEW queue felt opaque,
and that it was difficult to follow how decisions were made.
Q3: Why did you choose to split responsibilities into two teams?
A suggestion was made to separate DFSG review work from archive
operations. I considered this a good opportunity to reform the workflow
to accept new packages while ensuring continuity in crucial operations.
The aim was to create clear boundaries:
* Archive Operations continues with its established routines,
* DFSG review becomes a dedicated, separate and transparent process.
Q4: Does the restructuring affect the Archive Operations Team?
No.
Archive maintenance and release work require deep experience, and the
current Archive Operations Team has been carrying out these tasks
reliably, even during an emotionally difficult period. As long as they
wish to continue, I have no intention to change this team.
I want to explicitly thank them for their work -- including the smooth
execution of the latest point release.
Q5: What is the goal of creating a separate DFSG Team?
The separation creates room for a structured transition in DFSG
responsibilities. One possible outcome is a full rotation of the DFSG
team. Whether this will happen depends entirely on whether the new team
feels ready and confident. I will not make such a decision without their
agreement, but I want to encourage them to grow into the role.
My aim is for the next DPL to inherit a stable structure rather than a
turbulent one, which means the transition should not be delayed
unnecessarily. To provide predictability for everyone involved, my
current working assumption is that the new DFSG team can be ready to
take over primary responsibility toward the end of the year, followed by
a short handover period. This is not a fixed deadline, but it reflects
the timeframe I believe is realistic and desirable for a smooth
transition.
Q6: What are the new DFSG team candidates doing today?
The candidates are currently training by evaluating packages that are in
NEW. They are doing this without direct access to the NEW queue, which
is not ideal, but they are making steady progress.
In parallel, they are exploring options for improving NEW processing
itself. Their engagement and willingness to learn are essential for
building a more predictable and transparent workflow.
The new candidates have also begun publishing weekly public reports that
show what they reviewed, how decisions were reached, and where
improvements are being tested. These reports are an important part of
establishing the visible, predictable decision-making process that many
in the community have asked for.
Q7: How has the former FTPMaster team reacted?
The process has been difficult for many long-term members, which is
understandable when roles that people have held for decades change. I
have kept them informed promptly, sharing all relevant documents. The lack of
active feedback has made the right timing hard to judge, but the decision to
move forward is now taken.
Q8: Is the restructuring meant as criticism of the former team?
No.
Debian owes a great deal to the longstanding contributors dealing with
NEW processing, archive maintenance, and DAK development. Their work has
been essential for the project's stability.
This restructuring is not a judgment on past contributions. It is an
attempt to create a sustainable and transparent structure for the
future.
All previous DFSG delegates are explicitly invited to stay on in an
emeritus/advisory capacity and will be consulted on difficult cases
during the transition. The role of DFSG Wizard comes to mind.
Q9: Would mixing old and new contributors inside the DFSG team be an option?
Past experience in Debian has shown that structural transitions work best
when newcomers can build confidence in a predictable environment from day
one. Keeping the current social and technical tensions inside the same team
would slow down the necessary changes in transparency and onboarding.
Therefore the responsibilities need to be clearly separated.
All previous DFSG delegates (Thorsten, Joerg, Ansgar, and others) remain
highly valued for their expertise. They are explicitly invited to
continue in an emeritus/advisory role and will be consulted whenever the
new team encounters difficult cases, especially during the transition
period.
Mixing longstanding and brand-new members during such a transition
increases the risk of:
* unclear roles
* uncertainty for newcomers
* informal expectations for old members to train or supervise
* frustration and burnout on both sides
I want to avoid recreating those patterns.
The goal is to give the new DFSG candidates a predictable, supportive
environment from the start.
Q10: What kind of support would help the newcomers right now?
The new team is already working on publishing weekly transparent
reports and open review rationales (for instance in Gateway2New [1]).
Positive signals or occasional advice from the previous delegates would
be very welcome and would strengthen the collaborative spirit we all
want.
Q11: What about individuals specifically?
The former FTPmaster team comprises several people who have carried a
very demanding workload for many years. I want to explicitly acknowledge
the contributions of Thorsten, Joerg, Ansgar, Luke, and all other
longstanding team members. Their experience is still needed, and their
work remains deeply appreciated. I have full confidence that they will
continue to contribute in the Archive Operations Team or in whatever
role they choose.
Q12: Is it possible to join the new DFSG team?
Yes. If you are a Debian Developer and interested in contributing,
please reach out to me.
DFSG work requires care, judgment, and a willingness to learn. The
current candidates are already demonstrating this, and anyone who joins
will receive guidance and a clear path to grow into the role. The goal
is to build a capable, resilient team -- and motivated contributors are
very welcome.
Q13: How should feedback about this transition be given?
Constructive comments are very welcome.
Given the sensitivity of the topic, I kindly suggest reviewing messages
written in moments of strong emotion to help keep the discussion
productive and fair to everyone involved.
Kind regards
Andreas.
[1] https://salsa.debian.org/newgateway-team/reviews/
Attachment:
signature.asc
Description: PGP signature