Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2021-02-04 Thread Jan Korbel
Dear Debian developers, maintainers etc. I use Debian for many years. My primary and only installation for work is unstable installed in 2003 and i updated this one *many times*. I love Debian because of freedom from more points of view. One PoV is possibility to choose software component which

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2021-01-02 Thread Matthew Vernon
Hi, I see that network-manager 1.28.0-2 has been uploaded, with (inter alia) the following changelog entry: * Demote libpam-systemd to Recommends. This allows users to use and experiment with other init systems. Such a setup is neither tested nor fully supported and users need to be aware

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-28 Thread Sean Whitton
Hello, On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote: > On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote: > >> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote: >> > My reasoning is that init scripts are the end goal, and that elogind is >> > just a symptom of that end

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-28 Thread Sam Hartman
> "Russ" == Russ Allbery writes: Russ> We do drop features all the time between stable releases, Russ> though, and generally that too is at the maintainer's Russ> discretion. The package maintainer's normal obligation in Russ> Debian isn't to keep everything working that

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-28 Thread Russ Allbery
Sam Hartman writes: > The issue that came up in the policy discussion is that there may be > implications for removing an init script. As an example upgrades may > break. In the case of NetworkManager, you might find on an upgrade from > buster to bullseye that you no longer have network

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-28 Thread Vincent Bernat
❦ 28 décembre 2020 10:32 -05, Sam Hartman: > But for example, we have a rule that is fairly basic to our community > that we don't break upgrades, or at least we try hard not to. This is becoming harder and harder because we pile more and more choices (init choice, initramfs choice, merged-usr

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-28 Thread Sam Hartman
> "Russ" == Russ Allbery writes: Russ> I think this clearly and unambiguously says that maintainers Russ> can depend on unit support and drop init scripts from their Russ> packages if they so choose, and that this choice only requires Russ> as much justification as rejecting

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-27 Thread Bdale Garbee
Russ Allbery writes: > I assumed that if option B won, some > maintainers would drop init scripts, and therefore if folks wanted to > maintain a set of working init scripts, they'd need to look at different > options than ensuring they were incorporated into each package. I agree, this was my

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-27 Thread Russ Allbery
gregor herrmann writes: > What surprises me in this discussion: My very broad summary of the GR > result was "systemd is the top priority, other init systems are > supported on a best-effort basis", and now I'm reading statements which > sound to me like "looking into new/future/niche init

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-27 Thread gregor herrmann
On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote: > On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote: > > My reasoning is that init scripts are the end goal, and that elogind is > > just a symptom of that end goal, and that therefore talking about > > elogind in isolation serves no

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-27 Thread Sean Whitton
Hello Wouter, On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote: > My reasoning is that init scripts are the end goal, and that elogind is > just a symptom of that end goal, and that therefore talking about > elogind in isolation serves no purpose. The GR specifically mentions elogind

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-27 Thread Wouter Verhelst
Hi Sam, On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote: > > "Wouter" == Wouter Verhelst writes: > Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote: > >> I think that we should either decide that > >> > >> 1) NetworkManager should support elogind > >> > >> or

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-27 Thread Sam Hartman
> "Wouter" == Wouter Verhelst writes: Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote: >> I think that we should either decide that >> >> 1) NetworkManager should support elogind >> >> or >> >> 2) That we haven't seen enough development

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-26 Thread Wouter Verhelst
On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote: > I think that we should either decide that > > 1) NetworkManager should support elogind > > or > > 2) That we haven't seen enough development of alternatives to systemd > and the project consensus on the GR has changed. Personally,

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-23 Thread Mark Hindley
Elana, Thanks for passing this on. On Mon, Dec 21, 2020 at 03:36:45PM -0800, Elana Hashman wrote: > Less than 1% of users are installing sysvinit-core, with a steady > downward trend.[1] I accept that the number of users is small, although the figures referenced omit users of openrc and runit.

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-23 Thread Ian Jackson
Matthew writes: > * We've talked about the burden already; there are people willing and > able to help with this, and that offer remains good, be that by > providing patches, MRs, help with bug reports on non-systemd systems, > NMUs, or some other mechanism that Michael would prefer I think

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-23 Thread Matthew Vernon
Hi, On 21/12/2020 23:36, Elana Hashman wrote: The maintainer, Michael Biebl, reached out to the tech-ctte privately. I have summarized his reasoning for why he dropped support for elogind and the init script that prompted this bug: Thanks. There's little point trying to have this discussion

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-21 Thread Elana Hashman
On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote: > > 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

Re: Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread lorenzo
On Wed, 16 Dec 2020 11:48:52 +0100 Philip Hands wrote: > Are Simon's suggested dependencies are better in this regard? As far as I know > default-logind | logind works fine, but something like > systemd-sysv | network-manager-nonsystemd, won't for the same reason mentioned in my previous

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread Philip Hands
Matthew Vernon writes: > On 14/12/2020 21:56, Philip Hands wrote: > >> Could I just check if there's a point of common acceptability which both >> sides of this discussion could live with? > > [...] > >> My suggestion for a mutually bearable solution would be that the >> network-manager package

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread Ansgar
On Wed, 2020-12-16 at 14:46 +, Matthew Vernon wrote: Not is it straightforwardly clear that "alternative init systems" should in fact be interpreted to mean "alternative init systems (but not sysvinit)". The GR text mostly seems to talk about *exploring* alternatives; continuing to maintain

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread Sam Hartman
> "Matthew" == Matthew Vernon writes: Matthew> On 15/12/2020 22:07, Sam Hartman wrote: >>> However, Debian remains an environment where developers and >>> users can explore and develop alternate init systems and >>> alternatives to systemd features. Those interested in

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread Matthew Vernon
On 14/12/2020 21:56, Philip Hands wrote: Could I just check if there's a point of common acceptability which both sides of this discussion could live with? [...] My suggestion for a mutually bearable solution would be that the network-manager package could have its dependency on

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread Matthew Vernon
On 15/12/2020 22:07, Sam Hartman wrote: However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging

Re: Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread Philip Hands
lorenzo writes: > Hi all, > >> My suggestion for a mutually bearable solution would be that the >> network-manager package could have its dependency on libpam-systemd >> changed to instead be something like: >> >> libpam-systemd | network-manager-nonsystemd > > Please consider that apt has

Re: Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-16 Thread lorenzo
Hi all, > My suggestion for a mutually bearable solution would be that the > network-manager package could have its dependency on libpam-systemd > changed to instead be something like: > > libpam-systemd | network-manager-nonsystemd Please consider that apt has issues with or group

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Sam Hartman
I had a great discussion with Mark Hindley about this issue a few months ago. I'd like to summarize what I said in that discussion as input to the TC. But I'd also like to start out by reminding us all what we said in the GR text that we agreed to. As one of the contributors to that text, you

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Vincent Bernat
❦ 15 décembre 2020 11:14 GMT, Mark Hindley: >> Okay, great, I now see a clearer argument in favour of dropping the init >> script: enabling the maintainer to preemptively avoid dealing with bugs >> which are likely to generate hostility, rather than just the idea that >> there could be bugs

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Sean Whitton
Hello, On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote: > Sean and Simon, > > On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote: >> > In the cases where the regression was accidental, ideally, the answer >> > would be someone calmly and politely offering a tested patch, but it

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Mark Hindley
Sean and Simon, On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote: > > In the cases where the regression was accidental, ideally, the answer > > would be someone calmly and politely offering a tested patch, but it > > sadly seems equally likely to result in hostility, and I think it's

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Mark Hindley
On Tue, Dec 15, 2020 at 09:51:56AM +, Simon McVittie wrote: > On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote: > > Could I just check if there's a point of common acceptability which both > > sides of this discussion could live with? > > > > libpam-systemd |

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-15 Thread Simon McVittie
On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote: > Could I just check if there's a point of common acceptability which both > sides of this discussion could live with? > > libpam-systemd | network-manager-nonsystemd Presumably this is an optimized form of what we perhaps conceptually

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-14 Thread Philip Hands
Sean Whitton writes: > It is difficult to think further about this without input from the > maintainer as to how much this was a part of his motivation, and what > experiences he has had led him to think in that way. Hi All, Could I just check if there's a point of common acceptability which

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-14 Thread Sean Whitton
Hello, On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote: > On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote: > >> Participants in the thread who have argued on that side of the >> discussion seem to implicitly rely on the idea that a package maintainer >> is responsible for

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-14 Thread Simon McVittie
On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote: > The dependency issue is more challenging. As I said earlier in the thread, if we don't want to overrule on the logind dependency, then I don't think overruling on the init script would make any sense (whereas overruling on the logind

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-13 Thread Sean Whitton
Hello Simon and others, On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote: > If we are unable to use particular system services (in this case NM) with > a particular non-default init system without putting extra responsibility > on the maintainers of those system services, then I think

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-12-01 Thread Mark Hindley
Josh, On Mon, Nov 30, 2020 at 04:24:28PM -0800, Josh Triplett wrote: > If (hypothetically) network-manager upstream > decided to remove those legacy fallbacks, the maintainer would then be > in a position of either: But that is not what this particular discussion is about. Personally, I have no

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-30 Thread Josh Triplett
On Mon, 30 Nov 2020 10:55:44 + Mark Hindley wrote: > On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote: > > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > > > #921012 is about changing network-manager to Depend upon "default-logind | > > > logind" rather than

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-30 Thread Matthew Vernon
Hi, On 29/11/2020 16:59, Simon McVittie wrote: Some procedural points, without going into the merits of the technical committee doing as you ask or not: Broadly, I expect the TC to know their procedural stuff better than I do, but I'll try and answer your points :) On Wed, 18 Nov 2020 at

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-30 Thread Mark Hindley
Simon, Thanks for your clear and insightful comments. On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote: > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > > #921012 is about changing network-manager to Depend upon "default-logind | > > logind" rather than

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > #921012 is about changing network-manager to Depend upon "default-logind | > logind" rather than libpam-systemd This is a change that is *sometimes* appropriate, but sometimes not, depending on what facility the dependent package

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Sat, 21 Nov 2020 at 10:47:17 +0200, Wouter Verhelst wrote: > On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote: > > 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) > > This

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Thu, 19 Nov 2020 at 21:04:00 -0800, Elana Hashman wrote: > It would be much appreciated if Michael Biebl or another maintainer from > the Utopia team could add some context here. Most of the people in the pkg-utopia team are not active contributors to most of its packages, so I don't think

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
On Thu, 19 Nov 2020 at 11:40:20 +, Ian Jackson wrote: > My view is > that the behaviour seen in #921012 and #964139 is an outrage I don't think this is constructive, and if a package's maintainer doesn't want to enter into conversations, this doesn't seem like an approach that will change

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-29 Thread Simon McVittie
Some procedural points, without going into the merits of the technical committee doing as you ask or not: On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > I invite the technical committee to rule that: > * The network-manager init script should be restored > * Network-manager should

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-21 Thread Simon McVittie
On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote: > I don't think this is very common. Init scripts are very specific to a > distribution. A Debian init script cannot be used for Redhat. A SUSE > init script does not work with Redhat. I find doubtful that the > compatibility would be

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-21 Thread Vincent Bernat
❦ 19 novembre 2020 09:04 GMT, Matthew Vernon: > 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. I don't think this is very common. Init scripts are very specific to a distribution. A Debian

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-21 Thread Wouter Verhelst
On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote: > [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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Elana Hashman
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Tianon Gravi
(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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Josh Triplett
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Josh Triplett
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Sean Whitton
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Sean Whitton
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Sean Whitton
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Felix Lechner
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Ian Jackson
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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-19 Thread Matthew Vernon
[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

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Josh Triplett
On Wed, 18 Nov 2020 17:33:26 + Matthew Vernon wrote: > This bug report relates specifically to bugs in the network-manager > package (#921012, #964139) but has broader implications, particularly > around what it means to "support the efforts of developers"[0] working > on support for

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Philipp Kern
On 18.11.20 18:33, Matthew Vernon wrote: > Package: tech-ctte > Control: block 921012 by -1 > Control: block 964139 by -1 > X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk > > Dear Technical Committee, > > This bug report relates specifically to bugs in the network-manager > package

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Felix Lechner
Hi, On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon wrote: > > I invite the technical committee to rule that: What a great read! This message must be among the best prepared, and most polite, to come before the committee. Kind regards, Felix Lechner

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Matthew Vernon
Package: tech-ctte Control: block 921012 by -1 Control: block 964139 by -1 X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk Dear Technical Committee, This bug report relates specifically to bugs in the network-manager package (#921012, #964139) but has broader implications,