[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 <ijack...@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