Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
1. Basic principles
Josh Triplett writes:
> I do not believe it falls within the scope of the technical
> committee to override a decision already decided by a project-wide
> GR,
No-one is asking the TC to override the GR. In fact, Matthew is
asking the TC to *implement* the GR.
> or to "interpret" the text of a GR issuing a nontechnical policy
> document in ways that may undermine the decision made in that GR and
> document.
Obviously the TC ought not to undermine the GR. What counts as
undermining the GR and what counts as implementing appears to be a
matter of debate.
> Thus, I would suggest that the technical committee should decline to
> rule on any matters already decided by the GR.
On the contrary, if the GR is to be effective, it must be honoured.
That means that if an individual maintainer or contributor does not
respect the GR decision, the decision should be enforced by the
project's existing governance mechanisms.
2. Misrepresentation of the GR decision substance
> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that package.
This is true of course. But that is the key role of the maintainer.
As recognised in the GR text.
> The GR encouraged developers to work with each other; it did not
> *mandate* developers to spend their time and energy supporting
> alternative init systems,
This is quite simply false. End of 2nd para of the winning option:
| It is important that the project support the efforts of developers
| working on such technologies where there is overlap between these
| technologies and the rest of the project, for example by reviewing
| patches and participating in discussions in a timely manner.
This TC bug is precisely about such a situation. As Matthew explains
in his most recent mail, the provision of init scripts is precisely
such a situation, where by fasr the most practical way to deal with
"such technologies" (init scripts) is to acknolwedge the "overlap with
the rest of the project" (by putting the scripts in the packages for
the daemons).
That the dispute is about "overlap" is even more true about #921012,
which is about a Depends.
3. Analysis of the winning vs non-winning options
Josh looks at some of the non-winning options, and uses the fact that
those non-winning options were defeated as arguments *against* their
contents. Our voting system is specifically set up to allow multiple
different variations on a theme, so this is not a valid approach.
> The GR contained options for requiring ("must"), or even strongly
> encouraging ("should"/"important"), developers to maintain sysvinit
> support; those options did not win.
It also contained a non-winning option (F) making it clear that bugs
like #921012 and #964139 would be treated as wishlist.
> The bug did in fact have input from the maintainer, the day it was
> filed: it was tagged as wishlist.
Indeed, the maintainer is behaving as if option F had won.
4. Purpose of the GR, and overall intent of the winning option
> One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was,
> in large part, to settle with finality many ongoing case-by-case
> disputes about alternative init system support,
I think that was the aim of the proponent. Unfortunately, the winning
option did not support that desire.
Having spoken to a number of people both before after the vote I have
the impression that the Developers as a whole were not keen on a long
text which explicitly dealt with various matters in dispute and were
fed up of being asked these kind of questions in GRs and hoped the
project could behave like grown-ups. Sadly this seems to have been
over-optimistic.
5. Role of the TC
Josh disputes that the TC has an appropriate role here, asserting the
GR has pre-empted the TC's role. However:
| Maintainers use their normal procedures for deciding which patches
| to include.
The TC is explicitly empowered to exercise the maintainer's
decisionmaking authority, via its power to overrule a maintainer
decision.
Furthermore, the TC can clearly make its opinion known. My view is
that the behaviour seen in #921012 and #964139 is an outrage which
ought to result in DAM action. It would be open to the TC to make a
statement strongly criticising the maintainer's behaviour and
suggesting that the Community Team and/or DAM ought to intervene.
Ian.
--
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.
Reply to: