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

Reply via email to