Bug#975075:
[I have consolidated responses to multiple bits of quoted text here, in
an effort to consolidate responses to variations on the same points, in
the hopes that doing so will avoid proliferating variations on a common
theme.
Also, the title of this bug itself presumes a disputed point of view.]
On Thu, 19 Nov 2020 11:40:20 +0000 Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> 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.
> > 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.
That is an adverse interpretation that I do not believe is supported by
either the text of the GR or the intentions of those voting for it.
I would also like to make the observation that, both during the voting
for the GR *and* shortly after the GR, people opposed to this GR
repeatedly stated that the winning option would allow package
maintainers to decline to support alternative init systems if they did
not wish to support a proposed change; some of those opposed to this GR
outcome even suggested that it would make systemd effectively mandatory.
(This has not turned out to be the case, in practice.) I find it
interesting that that was the stated interpretation used to oppose the
GR and subsequently bemoan the outcome, but yet now an alternative
interpretation surfaces that would paint the outcome as though there
were a *mandate* for maintainers to always support alternative init
systems.
To be clear: I don't believe the intent of the GR was for all package
maintainers to *systematically* remove init scripts or alternative init
support, and I don't believe that's what happened here. If I believed
that there was some ill intent here to destroy alternative init systems
(rather than simply a desire to avoid expending time and energy on
them), I would not look favorably on that. I also don't believe that the
intent of the GR was to *force* maintainers to merge alternative init
support. Given the evident desire of some package maintainers to avoid
expending effort in ongoing maintenance of support for alternative init
systems, it would have been desirable to seek alternatives that remove
that burden from the package maintainer, and shift it to those working
on alternative init systems. Instead, it appears that the moment a
package maintainer declined the solution that would be the least work
for those working on alternative init systems, the matter was escalated
to the TC rather than seeking alternatives.
To the extent the TC wishes to solve the more general problem rather
than the specific case, I would propose that honoring the intent of the
GR would be to request potential solutions that appropriately
compartmentalize the work of maintaining alterntive init support to
remove it entirely from the package maintainer. The TC does not do
detailed design work to generate alternatives that were not put before
it, but it would certainly be within the remit of the TC to request that
others do so, and to evaluate such alternatives if a consensus cannot be
reached. But as far as I can tell, there was *no* apparent effort to
propose any such alternatives; the matter was simply taken to the TC
once the first proposal was declined.
This is *not* as simple as "just merge the init script and Depends
change". It has also included other ongoing work each time a new
compatibility issue arises. Past evidence suggests that this has proven
to be a source of ongoing maintainer burden, despite claims to the
contrary.
> > 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.
So it would unfortunately seem. One would have hoped we were all debated
out after the GR, and that the GR could stand as evidence of the outcome
of that debate.
As stated in my previous mail, the *least* favored option in the GR vote
was "Further Discussion", and yet here we are, having Further
Discussion.
> > 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 maintainer is also empowered to decide whether or not to include any
given change, if they deem the cost/benefit tradeoff inappropriate.
> > 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.
Two sentences prior:
> Those interested in exploring such alternatives need to provide the
> necessary development and packaging resources to do that work.
It is not up to those proposing those alternatives to unilaterally
select the tradeoffs between the amount of work they put in and the
amount of work they mandate the package maintainer do for them. That
includes, by way of example but not limitation: bug triage, dealing with
multiplicative additional user configurations, incorporating new
upstream versions, managing user expectations, asking "what subset of
this functionality I'm looking to use is supported by alternative
implementations", and dealing with the ongoing looming threat of "don't
do anything that might break alternative init compatibility or we'll
drag you to the TC".
Package maintainers are obligated to review patches in a timely manner;
they are not obligated to include those patches over their own
objections. Package maintainers are obligated to participate in
discussions; they are not obligated to always defer to the opposing
viewpoint in such discussions, and it is not a sign that collaboration
has utterly failed if the maintainer declines to accept the first
proposal put in front of them. Perhaps you might wish that a maintainer
would spend *more* time attempting to seek a solution, but spending time
devising an acceptable solution falls under "Those interested in
exploring such alternatives need to provide the necessary development
and packaging resources to do that work." It is not up to the people
proposing a patch to determine if that solution is acceptable, or if
that solution will appropriately handle the ongoing maintenance burden
associated with that patch.
> That the dispute is about "overlap" is even more true about #921012,
> which is about a Depends.
The dispute in that particular issue is largely over whether the
alternative dependency provides the necessary compatibility, as well as
whether it will continue to do so for future requirements in a timely
fashion. There are, again, other ways such issues could be solved as
well.
> 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.
I am primarily using the text of the non-winning options as evidence for
the interpretation of the text of the winning option by contrast. For
instance, the semantic use of "may" as opposed to "should" or "must"
(and equivalent) is supported by the presence of alternative options
that used "should" or "must". There were certainly many, many mails to
that effect as well during the GR discussion.
This issue is, in effect, attempting to retroactively interpret "may" as
though it had said "should" or "must".
> 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.
I have not disputed this. The TC *is* empowered to overrule a
maintainer, as a last resort. I am arguing that the TC is *not*
empowered to issue or enforce a systematic policy contravening the GR.
Separately, I am further arguing that the TC should not overrule the
maintainer in this specific case. But I am not suggesting that the TC
*cannot* do so in this specific case, only that it *should* not do so
lightly, and that it *must* not do so in a way that contravenes the GR.
Other systematic things that the TC could do would include encouraging
the development of further alternatives beyond the *one* that has been
presented.
So, I absolutely think the TC has an appropriate role here, just not the
one envisioned by the reporter of this issue. I would have preferred to
not see this escalated to the TC, but now that we're here, by all means
let's settle this, ideally in a way that ensures we don't end up *back*
in front of the TC about this matter ever again.
- Josh Triplett
Reply to: