Bug#975075: marked as done (tech-ctte: Should NetworkManager support elogind?)

2021-03-17 Thread Debian Bug Tracking System
system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: tech-ctte Control: block 921012 by -1

Bug#975075: Closing as this has been resolved without the TC needing to intervene

2021-03-17 Thread Margarita Manterola
Hi, It's been a while since this bug was dealt with and I was tasked with closing it, I'm sorry that it took so long to write this reply. The technical committee declines to overrule the NetworkManager and udisks2 maintainer on this matter. Instead, by working together with the maintainer

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: analogies

2021-01-31 Thread Simon McVittie
Sorry for the delay in responding to this, but I wanted to wait until the technical question before the committee had arrived at a result before replying to it. On Thu, 19 Nov 2020 at 06:49:37 -0800, Felix Lechner wrote: > In Debian, users of 'sysvinit' strike me as such a "disfavored class".

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Sam Hartman
General arguments about how the TC should conduct its business do not belong on this bug. I'd appreciate it if replies to this message are directed to a different place than this bug. We've established that the TC is operating consistently both with its historical process and with currently

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Felix Lechner
Hi, On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi wrote: > > the ability to talk privately with the committee is something CTTE has > allowed for a long time Debian has many great traditions, but the Magna Carta is much older. I found a great article about it ([1], p. 5): "the simple human need

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Gunnar Wolf
Sandro Tosi dijo [Tue, Jan 26, 2021 at 08:47:22PM -0500]: > the ability to talk privately with the committee is something CTTE has > allowed for a long time; it's a two-sided coin: it can prevent heated > exchanges, but it can also leave a sour taste in the petitioner's > mouth. > > While i would

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-20 Thread Felix Lechner
Hi, Sorry to comment so late. A meeting about this bug may already be in progress. On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon wrote: > > The maintainer won't talk to me, nor will they engage with me (or anyone > else) on this thread, though they will it seems talk to the TC in private. In

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-18 Thread Sam Hartman
> "Russ" == Russ Allbery writes: >> I have not come to the TC to ask them to overrule the maintainer >> frivolously nor before exploring as many other options as I >> could. Russ> I understand (oh, boy, do I ever) how strained relationships Russ> are after the

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-17 Thread Matthew Vernon
On 17/01/2021 10:29, Andreas Henriksson wrote: Possibly getting off topic here, but I happened to read a bit of this discussion and while seeing your comment I thought it might be a good time to remind you about #934463. I agree it's off-topic here, so I've sent a message to that bug

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-17 Thread Andreas Henriksson
Hello Matthew Vernon, On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote: > [...], and while I hope your ruling will not result in a bonfire of > perfectly good init scripts, I hope that maintainers who decide to > ditch them will let us know so we can add them there [...] Possibly

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-16 Thread Russ Allbery
Matthew Vernon writes: > The maintainer won't talk to me, nor will they engage with me (or anyone > else) on this thread, though they will it seems talk to the TC in > private. > I think, though, that it is common ground between submitter and > maintainer that the Depends is necessary for

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-16 Thread Matthew Vernon
On 16/01/2021 01:39, Gunnar Wolf wrote: Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]: Please overrule the maintainer in #923387 so that it is can be used on systems with elogind; it has been tested and shown to work thus as well as being supported by upstream[1]. As it was

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-15 Thread Gunnar Wolf
Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]: > > If you intend the scope of this bug to involve overruling maintainers' > > decisions in packages other than NM, what other packages/bugs did you > > have in mind? Is it just udisks2/#923387, or are there more? > > I understand (but

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Sean Whitton
Hello, On Tue 12 Jan 2021 at 01:53PM +02, Wouter Verhelst wrote: > Maybe talk to debian-policy to come up with some wording to be added to > either the developer's reference or policy that discourages dropping > init scripts, but encourages talking to the maintainers of > orphan-sysvinit-scripts

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Wouter Verhelst
On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote: > [0] to that end, orphan-sysvinit-scripts is in NEW, Glad you're taking that route. I had been thinking of other things to suggest that would make your life easier while allowing maintainers to drop init scripts if they so desire,

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-11 Thread Matthew Vernon
Hi, On 10/01/2021 20:03, Simon McVittie wrote: If you intend the scope of this bug to involve overruling maintainers' decisions in packages other than NM, what other packages/bugs did you have in mind? Is it just udisks2/#923387, or are there more? I understand (but I don't think it has been

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-11 Thread Mark Hindley
agree that it would be wrong for it to make use of the logind virtual packages. Mark [1] progress-linux-base-system and debian-cloud-images-packages [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#224

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-10 Thread Simon McVittie
On Sat, 02 Jan 2021 at 18:36:23 +, Matthew Vernon wrote: > While [lowering NM's dependency on libpam-systemd from Depends to > Recommends] does address the co-installability of network-manager with > elogind, I would like you to still say something officially about the issue, > please, since

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:

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

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,