TL;DR: I think a GR is an appropriate tool for making this decision at this time. I disagree with Simon's characterization of the TC's powers and think it is valuable for us to think broadly about all the tools we have for making decisions, so I am responding here.
>>>>> "Simon" == Simon McVittie <s...@debian.org> writes: Simon> The TC can overrule individual developers (§6.1.4 in the Simon> Debian constitution), but it can't overrule a position Simon> delegated by the DPL, and the ftp team is such a position. We Simon> have had situations in the past where an issue involving the Simon> ftp team was brought to the TC, and the most we could do Simon> abotu it was to "offer advice" (agree among ourselves on a Simon> non-binding opinion, §6.1.5) and hope that the ftp team might Simon> reconsider their decisions on the basis of that advice. In the particular case involved, that might have been true, because it's not entirely clear that the matter is technical. however, the TC has another power: it can set technical policy under 6.1.1. For example to the extent that the FTP team's concerns are related to security, the TC could adopt security standards for the Debian archive and tools that manipulate the archive/maintain the archive. The ftp team could ignore that too, but the ftp team could also ignore a GR, and I think the DPL would be well justified for removing a delegate either for ignoring an override in a GR or for failing to follow sensible policies adopted by the TC under 6.1.1. (the DPL cannot remove a delegate over a specific decision, but I think removing a delegate for being out of alignment with properly executed project decision making can be appropriate.)