On Tue, 05 Dec 2017 at 14:50:00 +0000, Ian Jackson wrote:
> I appreciate that the configuration I am describing is quite fierce.
> Many people would hate it. I wouldn't use it myself. It shouldn't be
> the default.
Then why are you suggesting that the project should consider using
release-critical bugs to force Debian maintainers to choose between
patching this in, potentially against their upstreams' objections,
or getting the package they wanted to maintain removed from Debian?
That seems rather heavy-handed for a feature that you don't even want
to use!
Debian is a volunteer project and we don't/can't force contributors
to do anything; but the closest we come to forcing contributors to do
things is to say "Policy says you must do this, so either do this or
see your work removed from Debian". That is a large club to be wielding,
and if that's the way we're going, we should be careful what we wish for.
I certainly wouldn't want to arrive in a future where Firefox (or
Chromium, or npm, or pip, or Flatpak, or Snap) was removed from Debian
because nobody was willing to maintain a long-term patch to make it filter
addons by our particular view of Freeness - that would be particularly
perverse for the browsers, whose entire purpose is to download arbitrary
data, much of it executable, and very little of it Free.
> But the need for it is demonstrated by the existence of Debian
> derivatives which do a lot of this work.
They are welcome to do so, but I don't think we should demand new work
from Debian maintainers, enforcing it with the threat of removing the
relevant packages, for the benefit of those derivatives. The level of
work we should demand from Debian maintainers is what's necessary to
meet *Debian's* minimum standards, not someone else's.
smcv
