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
signature.asc
Description: PGP signature
