Hi Jörg,
Am Fri, Nov 07, 2025 at 10:36:40PM +0100 schrieb Joerg Jaspert:
> > > asking
> > That response is astonishing to me. The suggestion to split the team
> > originated inside the former ftpmaster team[1] and was raised on
> > multiple occasions.
>
> It does not come from the team. Looking at team communication all (talking)
> are either surprised or pissed off by your set of (planned) actions.
I have to disagree with that description. The idea of a team split was
raised inside the ftpteam itself -- notably during the DebConf24 BoF,
where all three attending ftpteam members agreed that clearer scopes
could help reduce overload and make onboarding easier.
Since then, I've repeatedly invited discussion on the topic, both
privately and publicly. Apart from two brief private notes expressing
discomfort, I've received no substantive alternative proposal or
feedback from within the team. If I missed any relevant internal
discussion, please share pointers -- I'm not aware of any.
The NEW queue and the ftp-master team have long been central to Debian's
functioning -- and also a recurring source of frustration for many
contributors. While the reviewers' dedication deserves full recognition,
we cannot ignore that the current structure has not evolved in step with
the project's growth.
One of the main challenges is not about workload or technical expertise,
but about communication. Delegates are not expected to agree with the
DPL or the wider project on every matter, but they are expected to
communicate. Delegation requires ongoing exchange -- both with the DPL
and the community -- to ensure accountability, transparency, and
alignment with project needs. When such communication breaks down
entirely, the delegation ceases to fulfill its purpose.
For that reason, I believe we must first address this social issue
before tackling procedural or technical problems. Communication is not
optional; it is an essential part of the role. A team that remains
unresponsive cannot be effective, no matter how skilled or experienced
its members are.
Looking ahead, any reform of the ftp-master area must therefore include
mechanisms that ensure regular communication and mutual accountability
between delegates and the rest of the project. This is not about blame,
but about ensuring that critical parts of Debian function in a way that
reflects our collective values of openness and collaboration.
Let me also take a moment to express my sincere gratitude for the work
you and the rest of the team have done over many years. The commitment,
expertise, and persistence required to keep Debian's archive functioning
are enormous, and your long-standing contribution to that effort is
deeply appreciated. At the same time, it has become clear that the team
structure has not been able to bring in and retain new contributors for
quite some time -- something we need to address if Debian is to remain
sustainable in the long term.
> > I intend to continue supporting both teams, in particular by helping the
> > DFSG & Licensing team build up the capacity and structure it needs.
>
> And looking at the git you have for delegations, you appear to have found a
> load of members already and plan to delegate them.
>
> I fail to see ANY talk with the existing team members about this. Do you
> plan on that?
Several individuals shared with me that they either don't agree with the
current procedures/philosophy indoctrinated, they feel intimidated to
reach out and fear retaliation and in form of delayed or more strict NEW
processing, and any combination of the above.
The lack of dialogue and responses from the current members
significantly contributes to those concerns above.
However and at the same time, all of the new members are committed to
Debian and are very interested in working with you to carry on the
impressive legacy that is "ftpteam". They do value the work you did, and
want to learn and build upon it.
Let's work together by having a conversation about what is important for
Debian as a whole and where we want to improve. The first thing that is
currently discussed is the available bandwidth for processing new.
Kind regards
Andreas.
PS: Jörg, on a personal note: I've always appreciated your clear and
constructive communication -- most recently in the Rust
requirements discussion
https://lists.debian.org/debian-devel/2025/11/msg00026.html
I hope we can continue this conversation in that same spirit.
--
https://fam-tille.de
Attachment:
signature.asc
Description: PGP signature