Hi Ian, Hi all,
We all know Debian is [dying], right?
[dying]: https://salsa.debian.org/rafael/debian-contrib-years
# Background
I only joined Debian in 2024 and since then one thing has become abundantly
clear to me: it's dying because potential contributors are put off by our
archaic, fragmented and most importantly not natively git-based workflow(s!).
Thank you Ian & Sean, infinitely, for your relentless work in this space <3.
First I'd like to paint you all a picture of what the boots on the ground
reality of mentoring and recruiting in younger in-person technical spaces
looks like today. In my case this is the Austrian/German CCC-affiliated'ish
Hackspace bubble perspective.
Essentially everyone uses Debian (or a certain popular derrivative) in
their work/life in one way or another. Nobody contributes.
Even just getting people to file bugs, Debian specific bugs, is an uphill
battle of reassuring them that, yes, someone *will* *actually* read them
(and if they don't I will).
Observation 1:
Young developers don't see Debian as a place where work gets done.
What they will do, very readily and with much gusto is hop on GH to file an
upstream bug or shoot a patch — no problem.
Observation 2:
Young developers are not lacking motivation to work on FLOSS.
Even the few Debian-positive people in my circles that get past our BTS
having it's pristine 1990s style with the form complexity of a university
exam and somehow miraculously muster the motivation to work on something
eventually get stumped.
They first try learning our sprawling, directionless, multi-generational
packaging tools and multitudinous workflows. Oh joy. Having a hard time
grokking how it's all supposed to fit together they run into road-block
after road-block.
Hell I still haven't figured out how to actually be productive with our
tools and I've been doing this packaging thing for years already.
Just the other day I had someone give me a blank stare as I tried
deperately to explain the difference between source packages and the five
(at least, right?) different flavors of git packaging repo layouts and
corresponding tools. Unfortunately they'd picked a package with a
debian/-only tree and they hadn't heard of debcheckout yet. gbp clone
doesn't grok that layout and hilarity ensued. Not.
At this point I'd expect motivated people might usually try to seek
help. Though many will not. Self-sufficiency is a matter of pride for many.
The ones that would try to find help just don't seem to feel inherently
comfortable with email or IRC anymore. I observe this reluctance first hand
on an ongoing basis.
If that weren't bad enough they know of flamewars past and some of our
set-in-their-ways maintainers they don't want to argue with and shy away
from our spaces on those accounts too.
Observation 3:
Young developers can't access the help they need to be effective.
If they somehow got this far this is where I suspect the journey will
usually end. Likeley with a hacky [downstream workaround] if it's a Debian
specific problem since we're talking about motivated and driven hackers
here.
They're going to scratch their itch one way or another. It's just a matter
of whether the path that benefits the most people looks like too much work
for the preceived reward. The upstream-first messaging really has taken
root, let me tell you.
[downstream workaround]: Switching distro entirely is also known to happen
depending on the circustances. Arch is popular since it quickly integrates
the upstream work these hackers prefer doing anyway. That's what benefits
the most people in their eyes I believe.
# FTP & tag2upload
Ian. The project is bleeding and you're telling me ... we've had the
bandaid ... in hand ... and could have applied it ... four years ago!?
Frankly I'm floored.
FTP-team's obstructing behaviour, well intentioned or not, has robbed us.
Not just of t2u, but the incremental improvements it enables. Their
inaction has cost us four years of new, young, motivated people joining the
project and actually improving things alongside us.
Debian could have been exponentially better by now, yet it's still the
same. To all who like things as they are I say: well done! You got what you
wanted. The bleeding continues.
The way I see it this isn't a matter of giving FTP-team some more time or
talking some more. They've had their time, they had their say and they
squandered it.
This is about stopping the bleeding. Keeping the only people I see doing
the work that needs to get done for the project to survive motivated.
We need to show them our support by getting the people at the very heart of
the project that are making them ineffective out of their way. If *they*
don't continue, who will? Before the heat death of the universe anyway.
Even if we have to delay the trixie release.
Even if we have to accept a drop in archive security and traceability.
So be it.
We'll live, but without acting on this the project might not.
Remember: The only truly secure computer system is one nobody can use.
In light of that the direction we're headed is, ultimately, making Debian
the most secure system. Good job team! :D
Get back to not doing what you're not doing if that's your goal.
I won't.
# Support
Ian, you have my full support in doing what is necessary to stop the
bleeding and I'll be happy to volunteer to help with the dak hack job if
that still makes sense with Simon's keyring idea on the table.
--Daniel
On Fri, Apr 04, 2025 at 10:08:50AM +0100, Ian Jackson wrote:
> Hi everyone.
>
> tl;dr
>
> We need to make an exceptional, short term delegation authorising
> the installation of tag2upload's signing key on ftp-master.
>
> We need two volunteers to take on this responsibility; please
> volunteer in response to this message if you can do it.
>
>
> INTRODUCTION
>
> Thanks to a lot of help from DSA, tag2upload is deployed, all
> according to spec! We are very excited about this.
>
> However, we can't start our closed beta because the ftpmaster team will
> not authorise tag2upload's signing key to upload packages.
>
> We asked them to install the key on 2025-03-14. After some
> resistance, they told us they could make their changes and install the
> key by the end of March. We've offered technical information, and
> asked how it's been going, and in particular when April arrived we
> asked about agreeing a new timeline. However, they have been ignoring
> our messages for weeks, and there has been no update, and no sign of
> any activity.
>
> The tag2upload developers have a DPL delegation which explicitly
> grants us a signing key with certain upload privileges. Therefore,
> the ftpmaster team does not have any authority to block us, in just
> the same way that they can't tell the Release Team that they can't
> make a point release. It's just not for them to say.
>
> They could, of course, refuse to offer the Release Team any assistance
> in making a point release actually happen. This is Constitution
> 2.1(1), the volunteer principle.
>
> ftpmaster don't want to see tag2upload in use, and so they are
> choosing not to respond to our requests to install the key.
> Therefore, we need to temporarily delegate someone else to do it.
>
>
> TEMPORARILY DELEGATE?
>
> We are all used to delegations as ongoing and not time-limited, but
> this is not their only purpose in our Constitution.
>
> Just as an NMU is how we fix RC bugs or implement TC decisions when
> the maintainer won't do it, time-limited delegations are the
> equivalent mechanism the Constitution provides for similar situations
> outside of the archive itself.
>
>
> WHAT ABOUT THE DPL?
>
> The DPL has been CC'd on all of the private messages between the
> tag2upload developers and the FTP team. We have seen *no response
> whatsoever* from him.
>
> Given this, and other interactions we have had or are aware of, we do
> not have confidence in the DPL's willingness to take the necessary
> action.
>
>
> THE 2024 AGREEMENT WITH FTPMASTER
>
> Q. Didn't you come to an agreement with ftpmaster last year?
>
> We did. It was explicitly signed off by both sides, here:
> https://browse.dgit.debian.org/dgit.git/commit/?id=e5512e874ddd755e2168b34d1b95f5f3ee487e71
> https://lists.debian.org/debian-vote/2024/07/msg00024.html
>
> That agreement involved us doing substantial additional work to
> support additional checks by dak (that no other core team thought
> worthwhile). It also envisaged ftpmaster making changes to dak, to
> perform those additional checks.
>
> We have spent the past eight months implementing our side of the
> arrangement. They have done nothing, and are still doing nothing.
>
> In other words, they are in breach of our agreement.
>
>
> FTPMASTER'S POSITION
>
> We don't know what ftpmaster think should happen next since they
> haven't said. There is no indication that ftpmaster will start the
> implementation work, nor that they are prepared to proceed without it.
>
> They are stonewalling us.
>
>
> DRAFT GENERAL RESOLUTION
>
> Once we have some volunteers:
>
> We exercise the power of the DPL (via Debian constitution 4.1(3)),
> to make a Delegation (8.2). We hereby delegate the
> tag2upload Key Installation Task
> to the following Task Delegates:
>
> - Name
> - Name
>
> Task description
> ----------------
>
> 1. Install the tag2upload package signing key on fasolo.
> (i) in such a way that dak will treat it identically
> to a key belonging to a normal uploading DD;
> (ii) or some other similar authority or abilities as
> is consistent with the tag2upload service's needs,
> and seems convenient to the Task Delegates;
> (iii) keeping all changes as minimal as possible.
>
> 2. Collaborate with the tag2upload Delegates.
>
> 3. Collaborate with the FTP Master Delegates, if they express
> an interest, but without introducing any significant delay.
> Final decisions lie with the Task Delegates.
>
> 4. Confirm with the tag2upload Delegates that things are working.
> Resolve any problems (with the key, or with other aspects of dak).
>
> 5. Document what was done by email to the FTP Master Delegates,
> and/or in git, as the Task Delegates consider reasonable.
>
> 6. When completed, or if significant obstacles are encountered,
> report to the debian-project mailing list.
>
> The Task Delegates should be granted by DSA whatever permissions are
> necessary to accomplish the task.
>
> This is a new delegation. It is limited to the duration of the
> task, or until withdrawn by present or future Project Leaders.
>
>
> REJECTED ALTERNATIVE - ADDING THE KEY TO THE DD KEYRING
>
> One approach that would let tag2upload function correctly, would be
> adding the tag2upload service key to debian-keyring.gpg, as if it were
> a human uploading DD.
>
> This is an alternative way to work around ftpmaster's unwillingness.
> One of them even mentioned it in one message, though it wasn't clear
> how serious they were.
>
> But this is a really unpleasant workaround. We would need to audit
> elections to check that the tag2upload key hadn't "voted". We would
> need to remember to subtract one every time we were calculating
> quorum. The keyring maintainers don't like the idea, and we don't
> either.
>
> Better is to have dak accept two keyrings with identical authority:
> debian-keyring.gpg, and a service keyring debian-tag2upload.gpg
> containing the tag2upload key. This seems to us like it would be easy
> (and lowest risk, given that this task may be performed by someone
> with limited knowledge of the codebase). So that is what we propose.
>
>
> Q. LET'S JUST GIVE FTPMASTER SOME MORE TIME
>
> ftpmaster have already had 8 months since our agreement last year, and
> did nothing during that time. When their inaction became the final
> blocker, they initially refused, then pleaded for more time (which we
> accepted), then missed their own deadline, then went back to
> stonewalling when we asked for a new timeline.
>
> We do not expect that any new deadline would be met. Setting a new
> deadline would simply delay matters, and then leave us back where we
> started. More generally, it is not the tag2upload developers' job to
> project-manage ftpmaster's implementation work.
>
>
> Ian
> for the tag2upload Delegates
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> 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.
>
Attachment:
signature.asc
Description: PGP signature