Hi Sean,
Am Fri, Apr 04, 2025 at 06:19:14PM +0800 schrieb Sean Whitton:
>
> I was the only FTP team member present at Debconf
Correction: Thanks to Luke Faraone (delegated ftpmaster), we had a BoF
in Busan[1], so there were actually two members of the FTP team present.
In addition, Utkarsh Gupta-who was an ftpmaster trainee at the time-was
also there, before later being removed from the (now empty) trainee
list[2]. I found Utkarsh to be a valuable discussion partner in Busan.
> and I also largely
> agree with the specific things you want to change. So I sat down to
> talk with you in the hope that I could provide some insight into
> possible routes for change. Since then I have also invested a lot of
> time in e-mail exchanges with you.
>
> The specific issues we both thought were most important were:
>
> (1) Creating a recruitment pipeline is very difficult because the
> ftpmaster delegation encompasses both running the archive with
> interpreting the DFSG, for purely historical reasons.
>
> So anyone who would like to try to improve our tooling *and* have a
> pathway to autonomous decision-making (i.e. maintainership) has to
> first become an FTP assistant, and that means learning loads about
> copyright. For many people: urgh! Bye.
>
> Similarly, someone who would like to take a lead in our
> interpretation of the DFSG and decisions about adding new packages
> can become an FTP assistant, sure, but then they can't progress to
> the delegated role unless they are also willing to take
> responsibility for dak. For many people: too much! Bye.
>
> So I said that we should work towards splitting the delegation into
> two, even if at first the list of members of each team starts off as
> identical. You agreed.
Yes, I agreed. Since many people were not present at the BoF in Busan
and may not have had time to watch the full video, I prepared a
transcript to make the discussion more accessible. The relevant section
on this topic can be found here[3].
> (2) It is FTP team policy that packages in binary-NEW receive a full
> copyright and licensing check as though they were completely NEW.
> Instead, both you and I think that binary-NEW should only about
> managing the binary package namespace, looking at whether the
> Breaks/Conflicts/Replaces look sensible, and the like.
I've long supported having a second pair of eyes on binary-NEW packages
for technical review, even well before becoming DPL. That kind of
feedback is extremely valuable and guarantees the quality of Debian.
However, I'm not certain this reflects an "official” ftpmaster policy.
In fact, in his mail[4], Scott explicitly stated he was "speaking only
for myself, not the FTP Team."
To my knowledge, there is no public documentation clarifying what the
actual policy for binary-NEW is. Moreover, I have clear evidence that a
full license or technical review is not consistently carried out. This
lack of consistency, transparency, and accountability makes it difficult
for developers to understand and trust the process.
> This is just one respect in which the FTP team's internal ideas
> might be out-of-step with the rest of the project. I argued that
> some GRs would be appropriate, and of course we'd want the existing
> delegates involved in drafting them, as much as they wanted to be
> involved. You agreed.
I know GRs are the most powerful tool we have in Debian, and they play
an important role in settling questions of broad project-wide consensus.
However, I'm not convinced that invoking a GR is the right approach in
this case. In practice, we can't compel volunteers to do work they
fundamentally disagree with-even if a GR were passed. The likely outcome
is not enforcement, but disengagement or resignation, which doesn't help
anyone.
During my past DPL term, I never got the impression that there was any
consensus within the FTP team on the need for improvements-at least,
this was never communicated to me as a team opinion. While opinions may
differ on what the priorities or next steps should be, I've not seen
willingness to discuss and improve. I believe building on a shared
interest through dialogue and collaboration would be more promising than
escalating through a GR.
What we need instead is to attract and empower more volunteers to take
on this crucial role-people who not only understand the technical
responsibilities involved but also share the wider developer community's
expectations for how the NEW queue should be handled. I do not see any
meaningful progress without more volunteers involved. I've tried hard to
communicate this both to the team and to the community-admittedly, not
always in the best way, but always with the best intentions. As much as
I would like to drive change, I firmly believe that a single DPL cannot
achieve meaningful progress without a dedicated group of volunteers
stepping up to take responsibility.
> (3) The current team is almost completely burnt out. On the NEW side, I
> am the only person who received enough reviews of my work as an
> ftptrainee to join the team, since February 2020 -- and I was very
> determined about it.
I really appreciate your persistence and commitment to the team.
> There have been multiple other trainees who
> wanted to work NEW but did not receive enough feedback from existing
> team members to learn what they needed to learn.
I have a strong sense that this observation of a lack of feedback is a
natural consequence of how volunteer work functions. Volunteers can
choose to focus on doing the work directly or invest time in training
others to share it in the long run. This isn't specific to the FTP
team-I've seen the same dynamic play out in other teams as well.
Do you think the core problem here is that choice-or are we actually
lacking people who are willing and motivated to serve as trainees in the
first place?
> On the dak side, there are so many things that could change that
> would benefit Debian, but there isn't the manpower to provide enough
> mentorship to new code contributors to get them implemented. The
> current team is able to keep the keys rolling over and releases
> happening, which is no small feat. We are all very grateful to them
> for it.
I don't fully agree here. As Ivo mentioned during the BoF in Busan[5],
he contributed to the Python2-Python3 migration and highlighted that
there is a script available to set up a private DAK instance for testing
patches.
I was very pleased to see this approach being used recently by
Maytham[6], who implemented one of the features discussed during the
BoF. His merge request was accepted after just two weeks, which I
consider an excellent turnaround time for a change within such a
critical part of our infrastructure.
This shows that external contributors do have a viable path to make
meaningful progress. I really applaud Maytham's initiative, and my
thanks also goes to Ansgar for reviewing and merging the change.
Regarding your earlier suggestion to split the current team: it would be
helpful to know which members of the ftpmasterteam primarily identify as
DAK maintainers. If there's interest in forming a more focused DAK team,
I believe Maytham would be an excellent addition to such a delegation.
> But we should have more. Here are three things that are not
> technically difficult but would improve things hugely:
>
> - we should throw away maintainer-uploaded binaries after NEW,
> so they get automatically rebuilt, instead of requiring make-work
> no-change uploads before migration is possible
> - we need binNMUs for arch:all packages
> - maintainers should be able to self-remove old binary package
> versions for specific architectures.
I fully agree that these would be useful enhancements-alongside the
other ideas discussed during the BoF. I'd love to see them tackled in
the same constructive way as the feature mentioned above.
That said, I'm not sure why this topic is being raised on debian-vote.
> We could have been benefitting from all these things for years.
> You agreed.
>
> I do not blame the existing delegates for not solving all these problems
> on their own -- not at all. They are volunteers, they do and have done
> what they can, and the work that they currently carry out is very
> significant in itself.
>
> And it is completely fine for other things to become more important to
> someone, other things both inside and outside of Debian.
> For example, I was barely active as an FTP assistant because I wanted to
> focus on Policy, the TC and tag2upload.
This relates to the recent discussion on this mailing list about
individuals holding multiple roles-in your case, roles that can
occasionally pull in different directions[7].
That said, I want to use this moment to acknowledge and thank you for
the significant volunteer time you've contributed across several
important areas in Debian. Even when perspectives differ, that
dedication is genuinely appreciated.
> Nevertheless, the DPL has the responsibility to ensure the core teams
> are fit for purpose, and it is far from clear that the FTP Team is fit
> for purpose.
I disagree with this general statement. I have great respect for the
individuals who volunteer their time to fulfill a critical role within
Debian. I believe I've consistently made constructive suggestions to
improve processes in line with modern needs, rather than questioning the
team's legitimacy or commitment. Both before becoming DPL and in this
role, I've made a point of expressing that respect clearly. I don't
believe it's helpful to encourage new volunteers by publicly declaring
the team they'd join as "not fit for purpose".
As Luke pointed out during the BoF, what's missing is a shared vision
for the future of DAK[8]. I also recall a remark from an unrelated
private discussion: "the way to achieve things in a community project
like Debian is to talk to people and come to solutions together." I
fully agree-and unfortunately, this isn't happening at the moment, which
I see as a serious issue.
The communication between the ftpmaster team and the broader developer
community is almost non-existent. More concerning still is the very
limited communication between the DPL and the team. I admit I had hoped
for more opportunity to improve this when I ran for DPL last year. The
lack of meaningful exchange has led to frictions-something I personally
regret-but more importantly, it represents a structural issue that
hampers Debian's progress.
While I've been able to speak with individuals (such as you and Luke as
well as the other in person meeting), those discussions, as helpful as
they are, cannot replace a transparent and reliable communication
channel. Without such a channel, we cannot move forward constructively.
> My basic question to you is: We agreed on almost everything that needed
> to be done. You had a team insider, me, available to ask for advice on
> how to approach certain topics, and what next steps to take. It has
> been a whole year. Why, then, has nothing changed?
I do not see the role of the DPL as simply following the agenda of a
single team member, especially when there is known friction within the
team, as reflected by past actions[7]. The suggestions you've made above
are good and constructive. However, the way you proposed to achieve
those goals in private contained details that I did not agree with, and
they conflict with how delegated teams in Debian are intended to
function. As DPL, I aim to gather advice from all sides and work toward
solutions through consensus. I believe that this is the only way to make
meaningful progress in a volunteer-driven project.
In case someone is interested in the actions of my term:
2024-05: Officially contacted ftpmaster team (including DebConf BoF
invitation for DebConf)
2024-06: Suggested ftpmaster sprint during DebCamp
2024-07: Ensured ftpmaster team member could hold a BoF at DebConf
2024-07: Held several discussions with Sean, Luke, and Utkarsh at
DebCamp and DebConf
2024-07: Moderated DebConf BoF
2024-08: Transcribed DebConf BoF[9]
2024-08: Suggested ftpmaster sprint (offering traveling support and
joining, including drafting an agenda - no response except
for one member mentioning inability to attend)
2024-09: Met one German ftpmaster team member at home, leading to
constructive discussions, specifically addressing legal
advice discussed in the BoF[1], the possibility of a
sprint, and the need to attract newcomers
2024-10: Discussed ftpmaster problems at MiniDebConf in Cambridge
2024-10: Collaborated with ftpmaster team member on draft for SPI
lawyers' for new processing[10] following previous meeting
2024-10: Asked ftpmaster team about ways to change binary-NEW policy
2024-11: Summarized what I learned about technical contributions for
non-team members in Bits for October[11] (which led to some
constructive contribution[6], demonstrating this approach
can be successful)
2024-11: Held further discussions about ftpmaster policy at MiniDebConf
in Toulouse and via email
2024-12: Asked for an update on tackling[10]
2025-01: Followed up for an update on tackling[10] + proposed sprint
to recruit new members
2025-02: Inquired about status to tackle[10] + sprint to recruit new
members
2025-02: Discussed future Bits about recruiting new members after one
active member resigned
2025-03: Published Bits with a recruitment statement that was not
properly labeled - confirmed and regretted.
2025-03: Attempted to meet another ftpmaster team member, but failed
2025-03: First visible contribution from someone encouraged to get
involved[6]
2025-03: Registered DebConf BoF to share my learnings and involve
the community. I intend to hold that BoF independently
whether re-elected or not and hope that the DPL will be
present
> Bluntly, to Andreas: why should we vote for you again if you weren't
> able to make any progress at all on your core reason for wanting to be
> DPL?
If you think someone else will be more effective in addressing these
challenges, you absolutely shouldn't vote for me. I have great respect
for the other candidates and will gladly support them - especially with
anything I've learned around the ftpmaster situation - if they are
elected. But if you trust that I've learned from the overly high
expectations I had going into my last DPL term, and believe I can now
put that experience to better use, then I'd appreciate your support.
Kind regards
Andreas.
[1] https://debconf24.debconf.org/talks/154-meet-the-ftpteam/
[2] https://ftp-master.debian.org/
[3]
https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt#L67
[4] https://lists.debian.org/debian-devel/2022/01/msg00231.html
[5]
https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt#L79
[6] https://salsa.debian.org/ftp-team/dak/-/merge_requests/286
[7] https://lists.debian.org/debian-vote/2024/06/msg00000.html
[8]
https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt#L98
[9]
https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt
[10]
https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/154-meet-the-ftpteam.txt#L161
[11] https://lists.debian.org/debian-devel-announce/2024/11/msg00000.html
--
https://fam-tille.de
