Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Margarita Manterola <marga@debian.org>:
> I'm sorry this took so long to be actioned by us. This is on me.
> 
> In previous bugs that have been raised to the technical committee
> it has already been discussed and agreed that the technical
> committee does not have the power to overrule official Debian
> delegates.  This covers the decisions taken for example by the
> FTP Masters or the Release Team.
> 
> Thus, we are closing this bug now, as it's not actionable.
> 
> We suggest that you work together with the FTP Masters in
> figuring out a solution to this problem.

I'm not sure I agree with this.  Firstly, it's not clear that the
acceptance or not of packages is a decision "for whom noone else has
responsibility" in the words of the Constitution ?  (That's funny
wording because it should say "for which" since decisions are not
people...)

Secondly, the request could be actioned by a non-binding statement by
the TC.

Thirdly, when you decline a complaint, I think the TC should give real
information about escalation routes.  "Work together with the FTP
Masters" is not the correct escalation route.

You should have advised Pirate that:
 * Pirate should first escalate the matter with leader@d.o,
   because although the DPL does not have the power directly to
   overrule the ftpmasters, the DPL _does_ have ultimate
   responsibility for the ftpmaster team and therefore does have a
   supervisory role.
 * If that does not yield an appropriate outcome, Pirate has the
   option of a General Resolution.
 * Alternatively, this could be seen as a question of policy.  It
   seems unlikely that ftpmster would act cotnrary to a clear
   statement in Debian Policy about when circular build-deps are
   acceptable.

I wouldn't be saying all of this if I agreed that Pirate's complaint
is without merit.  I think our general approach to circular
build-dependencies needs to be clarified.

Personally for example I think it's quite ridiculous that the only way
to get from the Haskell binaries in jessie to the Haskell binaries in
stretch is an undocumented chain of recompilations of packages from
snapshot.d.o.  If we let Haskell do that, why are we being so hard on
JavaScript ?

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

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