Hello,

I'm phrasing this as a question for Andreas but I would like the other candidates to offer their views on how they would try to improve the
situation. At the end I ask Andreas one question and the other
candidates some others.

In your Bits from the DPL at Debconf in Busan you told us that one
central reason you ran for DPL, if not *the* central reason, was to make changes to how the NEW and RM queues work. You presented us with a
timeline of how you had tried to engage with the FTP team to change
things, in various ways, had not received responses, and this had
culminating in running for DPL as a way to become the person responsible
for keeping the delegations functional.

I was the only FTP team member present at Debconf 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.

(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.

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.

(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. 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.

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.

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.

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.

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.

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?

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?

And to the other candidates: do you agree about the seriousness of these issues? How will you approach them differently? How will you achieve
more?

Thanks for reading.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmfvsiIZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQKVzEACZk7AISVquWM7L7TsdXueV Gm7s9L5vJw5zeXqvXmnHLF76AGN/0lAKKLtV0ML0X1RLst3Th1RKirwksj8/VSC9 UBTfMCpNjErr7NAKCJWiiNBzy1KM21ZZ8sKgki7vzZWx4GYwZVYbhboWy0Rfk3TH BxY0YTwrmlYMWwtH6pqDN9ynwfYHAWk4U7dP/EF6b8N2MqAXUmlX87TO8iNmCcw+ LM3C0oy45EU8dWtJKSlP0attvNiNwa6N5BOQlvZv+nVH3Yq64V21Lvuf5D/0EJcP nfItF4GL3MadJXD8GI8vrrKPKkij0gkccQg+A+fSpqb/Kaw6XIs+QM3MNvNwRPqt 14opSLwpn845b8biPdgU8NPJIPBOw2Au789XuWWbPP8rG5wCj2JyUEscIakZXJpL GF7b2fnDwMXCiY5dt3alzOzM7b5mSvgtyIIsZMzMSbWmlw8O/1Ir9MWSUaC/NHZj 1BgQ5HtODrPFDCHtlkffJwZmWXhhbChfZXZqP3Cl0rXvfLeIRiLDvza/0lh9I/Nl aMLy6jeKECAYLuVEnOmb/onSomrxoutBbG0Mhv96QDjQ4gCyus0puowOzfLcI5T9 zpUAblGMs7iXJHYyyKyYx54+OOOfBB2o4iauS4bFRxRQhqygi/LoaO7jhKzrCgbb D7PyjML1mqEKwr15lRoW8Q==ZNIp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hello Sean,

And to the other candidates: do you agree about the seriousness of these >issues?  How will you approach them differently?  How will you achieve >more?

To me looks like we should split the ftp team in two. One for the new queue handling, one
for the infrastructure.
If existing teams aren't interested in making the infra better, people can join without having
to know about licenses, trainees, and so forth.

To me, as example, I *really* would like epoch bumps to go in binNEW, to avoid accidental
bumping.

+ everything you said, let's create a new team just for the code and one for the reviews of copyrights.
(Existing members will be part of both teams, new members will have to choose eventually)

Also OTOH, existing members interested only in copyrights won't be bothered by people interested in code
(I'm not blaming you Sean! Unfortunately I couldn't find a better way of saying this, I mean that
the current situation is bad for everybody in my opinion, on both sides)

G.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Apr 04, 2025 at 06:19:14PM +0800, Sean Whitton wrote:

And to the other candidates: do you agree about the seriousness of these issues? How will you approach them differently? How will you achieve
more?

I think part of the reason here is that we have too many
responsibilities tied together that people _all_ need to satisfy,
I agree with you there; I think there's possibly even more.

I'd like to float the idea of 3 teams:

1. Archive License Auditing (ALA) team; that performs copyright review
[A License Compliance? team]
2. Archive Infrastructure (AI) team; that develops the infrastructure such
as dak
3. Archive Management (AM) team; that executes stuff like removing packages
and accepting them and what not.

(I went for archive here, there are other non-anachronistic name
options :D)

I think the enforcement there is rather a social one: AM should accept
packages from NEW, but only if ALA left a positive review for the
copyright aspects.

I believe that for binary-NEW we can remove the wait between accepting
the package and doing the copyright review. The license compliance
can be checked later and an RC bug filed :D

The separation between management and infrastructure is a bit unclear
perhaps, I'm not quite sure how it would work: Should AI just develop
the infrastructure or should it operate it, i.e. can they SSH to
machines and install new dak versions.


--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJn8E+MCRBvpFjdHbA/cUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmffUlfWoVbsLjHujAhXkWnR9C3sUyAkjMQc98MvHsc/ zRYhBE+1iKhMLd55p0x3h2+kWN0dsD9xAADFFBAAroBr0D8l4X1c65J50Nqx+jzn g3+fpHwO4vDf/+xSPX3fpKwufTsLrYDfWs0Ebr1rBzjZI58w2aU/JZRVCb9ak+Sz e/kwT5IPFfkX6XKGpZ2xW3khKCdyCvhfjs3GerFf3sfx9TbBY/MnyVx0YWoZBsxK rCdiADhhhmAjAhJEK/GvLFlwHAk1KqgRlxzJJUEC/yQsnZteZle7e2GfNjQ0HYJb C0dDcriO2P1RpGZ45YJPgmKdfJBJfuJktlT8PC/e5LNufy2Upl3Q2y5w2+wkRjW/ 2kRexZnNu+P7zW5KFmx5uMn00moEKVyBzTw7txJovAysL0L12mO186QfJNXFzYwz mqh4cYBRqY/RxWUQoqPkWQW4LOEMSLFPbhynx0fC2/VFxmM3Y57SeCp+7pVw0hi3 mbnAsmzzmyGJDM+kkdkfeRjz/xbA8iqXei58GcNTPhhp43sGFti+YNeyZr2+rzRO 9fGpR7PFBvYGZKtEPBBAKAnzk0eBU/isyT2E5vNJPEiTOTj4oVlP9/ctTekAkZ1n 2rAAawf4Uqa3nWCzo09bNplZuI6p8lT72L1nqrFc6bUCRjRTrKuwWKGoi2HFTs9C uLnmfYG2LeOcKh5a+ZH3SxnZTjKFjof1LoMInAOXRdhKNxmWKM5CtA5rND

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sat 05 Apr 2025 at 05:00pm +02, Andreas Tille wrote:

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.

Ah, yes, apologies to Luke.

To my knowledge, there is no public documentation clarifying what the
actual policy for binary-NEW is.

Yes, there is: <https://salsa.debian.org/ftp-team/manpages/-/blob/master/doc/ftp-new.7.man?ref_type=heads#L43>

I've directed you to this document several times now.

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.

Indeed, there isn't, but that's my point. The FTP team can't just
decide that things should be a certain way if the whole rest of the
project disagrees. That is not a sustainable situation.

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?

You're right that this problem exists elsewhere, yet more functional
teams manage to provide enough feedback to integrate new members anyway.

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.

Then what is meant to happen in Debian when constructive suggestions are
not enough? Who is responsible for fixing delegations, if not the DPL?

You have described the problems with the team, but have not proposed
doing anything other than carrying on as before by making suggestions
which will be mostly ignored.

Doing the same thing as before will not lead to different results.
The situation will self-perpetuate.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmfx/4IZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQFy9EAC7yymrUMxON4fZPyzh28L5 bO+C0Fkb4kqMVfzcIGvs3yQwbp6acWbbGFz8YE/TsDm/TIm1JLAv5yKMARrZCHNE Mueda+6hWAiqm3ZLzFVJkuHlaj94XJ2dljTNYmF28jieAbcRBiIwN5hahiO6r1W4 eJLeFXDSShDGKdZqV3AovRlSToMkw9OqSJFGYn+NSuIdbHjNZRR7Zm61Dx3IE5aD HyvnhcGPzTxR1u38Q27ZvyEoMHHRboWeu3Xp8mNtoJQYbp2EB7/4DuWoV+7lh9La c1jZwFHxdQU+31Xtej/gJ6jNBvML0Mn+WgvGUgMHNCoH6Y8x0O2p2P2G/qLaoPqt tdrLcm7J7XUH2hOWipNUZVPx63vbAfhgdgn5r3nIWS6KuXe6FRPkCqdK8hC1s4vo uPmnzAeRsZNjIsxgHrBl7aqtIARb14xtkv4rUjExMXIM1F04Drw+0guTWgQQNjhr jX7tE0IN0wnngyIn9qm4C+/9NtagfmXmg+GYFW4atTF7ntFfcW7041vpNZUiq/a9 X/HKHDtXVATg25W4+xX+mTBtVEZ41AAemTQyRkLgT13AJaQbgUgdKfshH30XWNpV PQ8lOKOFVtoHgcEn9SE+gDfY0ZGbFl2fuQ7cgIjuneE3T3rZh4QmyQjqe3KhbIZu U/QHHwANlTM5d6gBB9qj1Q==VJQ6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Andreas Tille writes ("Re: Question to all candidates: the FTP Team"):

Am Fri, Apr 04, 2025 at 06:19:14PM +0800 schrieb Sean Whitton:

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.

It seems like you are laying blame on Sean here.

But this is *your* failure. You had all the power. As Project Leader
you had all the management tools, and the whole resources of the
Project, available to you.

Sean's ability to give you an inside view *one* of those resources.
But it was *your* responsibility as DPL to solve these problems.
Your platform promised ftpmaster reform but you failed to deliver.

You are of course as DPL free to disagree with Sean's advice.
Indeed, *judgement* about whose advice to take is part of the job.
But you mustn't fail to deliver on your promises and then complain
about the advice you were given, that anyway you didn't follow.

What you write below about consensus, is IMO a big part of the reason
for your failure. It shows a complete lack of understanding of basic principles of governance.

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.

This is fundamentally wrong.

Delegates can be powerful. Certainly ftpmaster are powerful within
Debian. Any powerful institution risks becomeing a self-serving
empire. So powerful institutions need to be kept in check. To be
held accountable.

In the Constitution, the Project Leader is the way the Dwelegates are accountable to the project as a whole. But accountability does not
exist if it needs the permission of those supposedly being held
accountable.

What we need instead is to attract and empower more volunteers to take
on this crucial role

There is a precondition you are missing. Currently, the team is
toxic. It has more than one toxic individual (see Sean's message on
-private). It has a secretive and toxic internal culture (once again
see Sean's message, but also the report from another traineee who left
the team).

No-one will want to join a toxic team and put up with toxic people,
and no-one should be asked to do so. If they do, unknowlingly,
they're not likely to stick around. This is why multiple efforts to
recruit to the team have failed.

To renew this institution, we need to get rid of the toxicity first.
That means getting rid of the toxic people.

Yes, that is disruptive and risky. But the alternative is to allow
the current situation to persist, as you have allowed it to persist.

We see this same fear play out in other areas. We have important
packages maintained by toxic people, whom no-one will get rid of for
fear of leaving an unfillable gap. This attitude is a trap.

Ian.

--
Ian Jackson <[email protected]> These opinions are my own.

Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/04/25 3:30 pm, Ian Jackson wrote:

To renew this institution, we need to get rid of the toxicity first.
That means getting rid of the toxic people.

Yes, that is disruptive and risky. But the alternative is to allow
the current situation to persist, as you have allowed it to persist.

We see this same fear play out in other areas. We have important
packages maintained by toxic people, whom no-one will get rid of for
fear of leaving an unfillable gap. This attitude is a trap.

Do you not think that the same fear should be valid in the context of FTP team as well?

As previous trainees have pointed out, there's a learning curve. If experienced members
of the team leave (or are asked to leave) all of a sudden, it'd be problematic for new
folks to ramp up quickly and get things running.

What you propose sounds like a forceful removal of certain individuals from the team.
This may as well have a domino effect where remaining (non-toxic) members of the
team don't like the use of force and end up resigning.

Since the FTP team is so central and affects multiple areas in Debian, authoritatively re-structuring
this team (or any other Debian team for that matter) by the DPL does not sound like a very wise move.

Let me know what you think.

Best,
Nilesh

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)