Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Thu, Nov 19, 2020 at 04:20:46PM -0800, Tianon Gravi wrote: > > On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote: > > Any inclusion of work into a package necessitates *some* amount of > > development and packaging resources by the maintainer of that package. > > Even if someone else offers to shoulder some of that load, that does not > > eliminate the maintenance burden; in some cases, it may not even reduce > > the maintenance burden. > > Thank you for this. This puts into very straightforward words a > feeling I've had for ages but couldn't word well. > > In many projects I maintain outside Debian, I very frequently see this > belief that if someone else contributes the work to make something > possible (or it is otherwise perceived as "trivial" work), that > there's no work for the maintainer, when it actually *does* increase > the maintenance burden, often in ways the contributor cannot or will > not see (or in some extreme cases, refuses to). I caution folks from speculating too much on the maintainer's motivations and reasoning while they haven't yet had a chance to share their perspective on the bug. :) From what I can see reading through both #964139 and #960780, no technical rationale has been given for why the script was removed, only a statement that the removal was intentional.[0] It would be much appreciated if Michael Biebl or another maintainer from the Utopia team could add some context here. - e [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139#62 signature.asc Description: PGP signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
(Going to leave my own opinions on the underlying discussion here aside, but wanted to highlight/echo this bit:) On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote: > Any inclusion of work into a package necessitates *some* amount of > development and packaging resources by the maintainer of that package. > Even if someone else offers to shoulder some of that load, that does not > eliminate the maintenance burden; in some cases, it may not even reduce > the maintenance burden. Thank you for this. This puts into very straightforward words a feeling I've had for ages but couldn't word well. In many projects I maintain outside Debian, I very frequently see this belief that if someone else contributes the work to make something possible (or it is otherwise perceived as "trivial" work), that there's no work for the maintainer, when it actually *does* increase the maintenance burden, often in ways the contributor cannot or will not see (or in some extreme cases, refuses to). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#971515: Status as of last tech-ctte meeting
On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote: > There are a lot of fascinating edge cases and precedents and philosophical > questions about the function of a distribution here, and I think they > rightfully attract a lot of energy, but I'm worried this is at the cost of > losing sight of the core functionality provided by Debian. Because that > functionality is currently working, the people who are benefiting from it > don't know to weigh in. [...] > As a Debian developer, I appreciate the arguments about vendoring and the > desire to maintain Go libraries and the pride that we take in our work of > really understanding software and packaging it properly. > > However, as a Debian *user* of the kubernetes-client, I have to say that I > do not care in the slightest. The older, unvendored kubernetes-client > package worked great. The new, heavily vendored kubernetes-client package > works great. Both do exactly what I want, and I don't care at all, as a > user, which is in Debian. But if the package were removed from Debian, I > would be really unhappy. And if Helm and Argo CD were packaged for > Debian, I would be much happier, so if unvendoring them is the obstacle, > as a user I'm opposed to unvendoring! > > I want to push back a bit against the feeling that some things are > ill-suited for how Debian has historically packaged software and therefore > maybe Debian isn't the place for them, and we should instead ask people to > manage them outside of Debian (but somehow make this easy). > > First, while I appreciate and cheer Phil and Sean's optimism, there have > been a lot of plans in Debian historically to make something that isn't a > package easy to build and install, and they have basically never worked. > The way Debian makes something easy to build and install is by making it a > package. That's what our entire project is designed around, and I'm > dubious that we're going to be able to reproduce those properties with > something that isn't a package. > > Second, the point of Debian at the end of the day is that I can install it > on a computer and use it to get things done. The details we're discussing > here are important and work towards making Debian maintainable and > sustainable and to ensure that a quality bar has been met in terms of > security and legality and licensing, but I think it's important that they > are also means to an end and the end is not security and licensing per se. > We're not making a random collection of relatively secure software; we're > giving people programs that they can run while keeping them secure. We're > not just a classification system for what software is free; we're giving > people software they can use while ensuring that all of it is free. I > think it's worth occasionally stepping back and dwelling on that thought > for a moment and making sure we're picking the right strategy for meeting > our quality bar that allows us to still achieve the mission. > > This is particularly true for something like vendoring or the avoidance of > vendoring, which is not a core mission. It's not in the social contract, > and it's not a DFSG principle. It's a hard-won and very valuable piece of > experience with how best to sustainably make a distribution... but one > that was hard-won in the era of C programs and shared libraries and that > has generalized admirably to Perl and Python. It may generalize to other > languages and other mechanisms for distributing software. It may not! If > it doesn't, that's significant because it's such a deeply-engrained part > of our culture, but it's *not* a breach of our fundamental project goals. > We can consider new approaches here without becoming untethered, and > indeed may be able to achieve our primary goal *better* by expanding the > scope of software that we can include in the distribution and that can > therefore just work. > > I think there's a bit of a crisis of confidence in Debian because of how > much larger the free software ecosystem is now than it was when the > project started, how far away from doing everything through a distribution > a lot of developers have moved, and how many resources are flooding into > other areas that we have difficulty keeping pace with. One of the natural > reactions to that crisis of confidence is to pull back from these new and > difficult and unfamiliar areas and decrease scope to the things we know > we're really good at: packaging primarily C, C++, Perl, and Python code. > And that is a valid strategy; it's okay to just keep being very good at > something one is already very good at. But I think in the long term that > means Debian becomes something much different than it historically has > been. It means Debian would become a base on which other people would > build things, rather than a comprehensive collection of tools that covers > all the incidental things you need from a computer, and where people need > only reach outside of Debian for
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton wrote: > On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > > First, as a point of order (for which some authoritative guidance from > > the Secretary, CCed, would potentially prove useful): while the > > technical committee is empowered to handle various types of disputes (up > > to and including overruling an individual developer if necessary), I do > > not believe it falls within the scope of the technical committee to > > override a decision already decided by a project-wide 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. Any > > interpretation of the text of the GR would need to be based on the text > > and intent of the GR. (Intent could include discussion at the time, but > > would notably include the text of other options that did not prevail, as > > well as the status quo at the time that motivated a GR to change.) > > Changing that intent would require either another GR, or (per specific > > provisions included in the winning GR option) consensus among the > > project, not a TC ruling. > > > > Concretely, the GR explicitly acted by "Using its power under > > Constitution section 4.1 (5)", which is the power to "Issue, supersede > > and withdraw nontechnical policy documents and statements.". The > > Technical Committee does not have such "nontechnical policy documents > > and statements" within its ambit. Any interpretation of 'what it means > > to "support the efforts of developers" working on support for > > alternative init systems' would thus be an interpretation of such a > > nontechnical policy document. > > > > Thus, I would suggest that the technical committee should decline to > > rule on any matters already decided by the GR. This does not preclude > > the TC from offering advice, or potentially facilitating dispute > > resolution if asked to do so, or even as a *last resort* overruling a > > developer on a specific technical matter (if doing so does not go > > against the GR), but I don't believe it's within the scope of the TC to > > relitigate the GR to mandate support for alternative init systems. Any > > potential ruling here would need to avoid attempting to supersede the > > GR. [...] > In our dispute resolution role, the TC is empowered to decide upon the > two things about the contents of the network-manager package that we > have been asked to decide upon, as a matter of last resort. No-one > disputes that we can do this. (I agree with this paragraph, in case there was any doubt about that.) > We have also been invited to rule that "Similar init-compatibility > changes should not be blocked by package maintainers unless they are > defective on their own merits". Essentially we are being invited to > generalise the decision that we make about the network-manager package > to say that it would apply to similar cases. > > We might decide that the reasons we have for whatever decision we make > about the network-manager package do not generalise, and so we may > decline the invitation to make any more general ruling. > > But if we do think the reasons generalise, then we can generalise our > ruling without stepping outside of our dispute resolution role. For > example, we might say "if another CTTE bug was filed about the contents > of a package which was similar to this one in the following respects > ... then we would expect to issue the same ruling as we have here, > because we believe that our reasons for this ruling would apply to all > packages which are similar in the previously stated respects." > > Clearly we would not want to say anything which we thought contravened > the GR. However, I do not think there is any reason to think that > resolving this dispute would necessarily involve the TC interacting with > the GR in a way that the constitution does not permit. We are being > asked to decide about one package, and being invited to generalise in a > way that falls within the scope of our dispute resolution role. It would certainly be *possible* for the TC to suggest that it would systematically rule in favor of, to use these two issues as examples, including init scripts and alternative dependencies despite the maintainer not wishing to maintain them. What I'm suggesting is that, given that the slate of GR options included possibilities that would have required maintainers to do so by policy, and the developers declined to enact such a policy, it would be *especially* unfortunate if the common practice became to either systematically escalate to the TC or use the threat of such to effectively enforce a different policy. The GR encouraged people on all sides to collaborate in this area, not to pick a side and do everything possible to undermine the other side. It seems as though the current path thus far has been to present one option, and when that option was declined, seek enforcement from the
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 + Ian Jackson 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*
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton wrote: > Hello, > > On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > > I'd also like to address one other issue here. It would be easy to > > hypothesize, at this point, that some additional communication (or more > > verbose communication) from the maintainer might have helped here. > > However, I would express doubt that any more verbose version of "no" > > (e.g. a long-form explanation about undesired additional maintenance > > burden) would have led to any less escalation. I think the situation > > would still have ended up here, no matter how much time or energy was > > expended in writing responses. > > > > That seems particularly likely given the adversarial NMU directly > > attempting to override an active package maintainer's decision, which > > escalated the situation further. (Such adversarial NMUs have occurred in > > regard to alternative init support in the past, as well.) And I don't > > think anyone can reasonably suggest that they thought the change was > > made unintentionally (given that it was explicitly mentioned in the > > changelog), which makes the NMU a rather hostile escalation. > > > > I would ask anyone on the TC who feels that more verbose answers were > > desirable whether they think a more verbose answer would have had any > > effect on the outcome or subsequent escalations. > > Assuming for a moment that the TC does not decline to rule, it is going > to be very hard for us to make a good decision if we lack more detailed > input from the package maintainer. I'm not suggesting otherwise; I'm only asking the TC to refrain from suggesting that further communication alone, prior to this point, would have averted this situation. The original request makes such implications, so they may potentially have formed part of what the TC ruled on. (The TC does sometimes issue similar suggestions as part of its rulings, in what I think is generally a *good* practice of encouraging people to work things out and giving them guidance on how to do so.) > We can speculate as to whether the dispute would have proceeded better > or worse with more verbose messages from Michael before now, but it > would be beside the point. Thank you; that fully addresses this particular point.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > First, as a point of order (for which some authoritative guidance from > the Secretary, CCed, would potentially prove useful): while the > technical committee is empowered to handle various types of disputes (up > to and including overruling an individual developer if necessary), I do > not believe it falls within the scope of the technical committee to > override a decision already decided by a project-wide 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. Any > interpretation of the text of the GR would need to be based on the text > and intent of the GR. (Intent could include discussion at the time, but > would notably include the text of other options that did not prevail, as > well as the status quo at the time that motivated a GR to change.) > Changing that intent would require either another GR, or (per specific > provisions included in the winning GR option) consensus among the > project, not a TC ruling. > > Concretely, the GR explicitly acted by "Using its power under > Constitution section 4.1 (5)", which is the power to "Issue, supersede > and withdraw nontechnical policy documents and statements.". The > Technical Committee does not have such "nontechnical policy documents > and statements" within its ambit. Any interpretation of 'what it means > to "support the efforts of developers" working on support for > alternative init systems' would thus be an interpretation of such a > nontechnical policy document. > > Thus, I would suggest that the technical committee should decline to > rule on any matters already decided by the GR. This does not preclude > the TC from offering advice, or potentially facilitating dispute > resolution if asked to do so, or even as a *last resort* overruling a > developer on a specific technical matter (if doing so does not go > against the GR), but I don't believe it's within the scope of the TC to > relitigate the GR to mandate support for alternative init systems. Any > potential ruling here would need to avoid attempting to supersede the > GR. I have been thinking about this procedural issue and in the end I think that it is moot. Let me explain how things seem to me. In our dispute resolution role, the TC is empowered to decide upon the two things about the contents of the network-manager package that we have been asked to decide upon, as a matter of last resort. No-one disputes that we can do this. We have also been invited to rule that "Similar init-compatibility changes should not be blocked by package maintainers unless they are defective on their own merits". Essentially we are being invited to generalise the decision that we make about the network-manager package to say that it would apply to similar cases. We might decide that the reasons we have for whatever decision we make about the network-manager package do not generalise, and so we may decline the invitation to make any more general ruling. But if we do think the reasons generalise, then we can generalise our ruling without stepping outside of our dispute resolution role. For example, we might say "if another CTTE bug was filed about the contents of a package which was similar to this one in the following respects ... then we would expect to issue the same ruling as we have here, because we believe that our reasons for this ruling would apply to all packages which are similar in the previously stated respects." Clearly we would not want to say anything which we thought contravened the GR. However, I do not think there is any reason to think that resolving this dispute would necessarily involve the TC interacting with the GR in a way that the constitution does not permit. We are being asked to decide about one package, and being invited to generalise in a way that falls within the scope of our dispute resolution role. -- Sean Whitton
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > I'd also like to address one other issue here. It would be easy to > hypothesize, at this point, that some additional communication (or more > verbose communication) from the maintainer might have helped here. > However, I would express doubt that any more verbose version of "no" > (e.g. a long-form explanation about undesired additional maintenance > burden) would have led to any less escalation. I think the situation > would still have ended up here, no matter how much time or energy was > expended in writing responses. > > That seems particularly likely given the adversarial NMU directly > attempting to override an active package maintainer's decision, which > escalated the situation further. (Such adversarial NMUs have occurred in > regard to alternative init support in the past, as well.) And I don't > think anyone can reasonably suggest that they thought the change was > made unintentionally (given that it was explicitly mentioned in the > changelog), which makes the NMU a rather hostile escalation. > > I would ask anyone on the TC who feels that more verbose answers were > desirable whether they think a more verbose answer would have had any > effect on the outcome or subsequent escalations. Assuming for a moment that the TC does not decline to rule, it is going to be very hard for us to make a good decision if we lack more detailed input from the package maintainer. We can speculate as to whether the dispute would have proceeded better or worse with more verbose messages from Michael before now, but it would be beside the point. -- Sean Whitton signature.asc Description: PGP signature
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hello, On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > I'd also like to address one other issue here. It would be easy to > hypothesize, at this point, that some additional communication (or more > verbose communication) from the maintainer might have helped here. > However, I would express doubt that any more verbose version of "no" > (e.g. a long-form explanation about undesired additional maintenance > burden) would have led to any less escalation. I think the situation > would still have ended up here, no matter how much time or energy was > expended in writing responses. > > That seems particularly likely given the adversarial NMU directly > attempting to override an active package maintainer's decision, which > escalated the situation further. (Such adversarial NMUs have occurred in > regard to alternative init support in the past, as well.) And I don't > think anyone can reasonably suggest that they thought the change was > made unintentionally (given that it was explicitly mentioned in the > changelog), which makes the NMU a rather hostile escalation. > > I would ask anyone on the TC who feels that more verbose answers were > desirable whether they think a more verbose answer would have had any > effect on the outcome or subsequent escalations. Assuming for a moment that the TC does not decline to rule, it is going to be very hard for us to make a good decision if we lack more detailed input from the package maintainer. We can speculate as to whether the dispute would have proceeded better or worse with more verbose messages from Michael before now, but it would be beside the point. -- Sean Whitton
Bug#971515: Status as of last tech-ctte meeting
On Wed, Nov 18, 2020 at 10:26:21AM -0800, Russ Allbery wrote: > > I maintain a bunch of Kubernetes clusters as part of my job. Those > clusters are run by other people (cloud providers, data centers, etc.). I > need clients to talk to those clusters. When I first started working with > Kubernetes, I realized I needed a client, worried about how much of a pain > that would be, did an apt-cache search for kubernetes, found > kubernetes-client, breathed a sigh of relief, and ran apt install > kubernetes-client. I have subsequently not given Kubernetes clients a > second thought. > In priciple, the kubectl compatibility matrix says it only supports one minor version (older or newer). When you working with many clusters, the cluster version may not be compatible with the kubectl version in Debian stable. PS, in practice, the basic function of kubectl doesn't change much, and new kubectl with old cluster seems to work. As a user of upstream kubectl package user, I'm quite happy with it. I can always install the latest, or any old version. They keep all old versions in their apt repo. And with the nature of static link, their repo works well other parts of the system, regardless I'm running Debian oldstable, stable, or unstable. IMO, we should admit that current Debian way doesn't fit well for such softwares. signature.asc Description: PGP signature
Bug#971515: Status as of last tech-ctte meeting
Russ Allbery writes ("Bug#971515: Status as of last tech-ctte meeting"):
> [much stuff]
Oh, wow, Russ. Thank you very much. What an excellent piece of
writing. I agree entirely with all of it.
Ian.
(And I speak as someone who thinks that this newfangled "vendor
everything" and "just download that shit from the internet" approach
is hideously bad engineering practice.)
--
Ian JacksonThese 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.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On Wed, Nov 18, 2020 at 11:33 PM Josh Triplett wrote: > > I do not believe it falls within the scope of the technical committee > to override a decision already decided by a project-wide GR In the State of California we follow such a strict interpretation of ballot measures. While consistent with direct democracy, it is also widely blamed for a dysfunctional state government. [1] But even here, courts enjoy some leeway. Please consider Proposition 8. Widely publicized in 2008, it was a successful ballot initiative that banned same-sex marriage by amending the state constitution (yes, California can be conservative). A Federal District Court later ordered the State to ignore the people. While the appeals failed on narrow grounds, the original opinion that ended up standing was described as ruling that "the amendment was unconstitutional under both the Due Process and Equal Protection Clauses of the Fourteenth Amendment, since it removed rights from a disfavored class with no rational basis." [2] In Debian, users of 'sysvinit' strike me as such a "disfavored class". Personally, I find it outdated and would never use it again, yet based on how often the topic reappears, there are clearly people who think differently. Now similarly to Proposition 8, I believe the GR should bind the DPL and all delegates—but not the Technical Committee. It is our supreme court. Like Josh's message, I make a point of procedure. The Technical Committee should be free to rule. They could also decline, for example by citing the GR. As an aside, the Debian Constitution lacks any elevating language that by itself would make such daring projections of universal justice possible. In fact, our constitution mentions no "rights" whatsoever (except for a copyright notice at the bottom). That is why I had to resort to an outside precedent to make my point. The constitution's text also leads me to renew my call: Let's rewrite Debian's foundational documents together to promulgate inspiring ideals we can hold up in the sky. [1] https://openlibrary.org/works/OL16420003W/California_crackup [2] https://guides.ll.georgetown.edu/c.php?g=592919=4182204 [3] https://lists.debian.org/debian-devel/2014/11/msg00174.html Kind regards, Felix Lechner
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 JacksonThese 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.
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
[I don't need a CC, thanks] Hi, I know it was mentioned back in the day, but trying to re-ask it now: Wouldn't it be possible to ship init scripts for compatibility purposes from a sysvinit (or maybe a sysvinit-support) package? This would be the inverse of what happened back when systemd was introduced, which was about shipping service files that superseded existing init scripts. I have thought about this, and it seems like a bad idea for a number of reasons, including: 1) poor user experience - a package of initscripts would clutter /etc/init.d/ with a huge number of files (most of which would be no use to the user) 2) init scripts to need to change sometimes, typically that change will accompany a version change in the associated daemon (e.g. the CLI changes) - the most natural way to have this work seamlessly is for the init script to come with the daemon 3) many upstreams (esp. those who support BSD) ship a sysvinit file, again making the daemon (source at least) package the natural place to keep it. 4) difficulty reliably achieving seamless handoff from daemon package to a putative sysvinit-scripts package (e.g. packages that actively remove the init.d file from the installed system; keeping a users' modifications to the file) I understand that you might not want that maintenance burden, however it seems like the network-manager maintainers might not want that maintenance burden either. I think the burden concern is over-made here. This is not a case of "this init script has bugs that have been causing problems and no-one has fixed it", nor a bug report of the form "please write an init script". There is an extant, working init script. There are people more than happy to provide assistance should it need updating. I concede that collaborating with those people is non-zero effort, but this is not a case of "I want this work done and am not prepared to help do it". Regards, Matthew
