19:00:20 <marga> #startmeeting
19:00:20 <MeetBot> Meeting started Wed Mar 20 19:00:20 2019 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:20 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:29 <marga> #topic Roll Call
19:00:33 <marga> Who's here for the meeting?
19:00:38 <Mithrandir> Tollef Fog Heen
19:00:39 <marga> Margarita Manterola
19:01:02 <ntyni> Niko Tyni
19:01:03 <OdyX> OdyX
19:01:06 <OdyX> Didier Raboud
19:01:17 <OdyX> eh, long day…
19:01:19 <gwolf> Gunnar Wolf
19:01:25 <bremner> David Bremner
19:02:50 <marga> We are missing a fil and smcv apparently
19:02:57 <marga> Let's move to the next topic
19:03:12 <marga> #topic Review of previous meeting AIs
19:03:32 <marga> http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-02-20-18.58.html is the summary of the previous meeting
19:03:57 <OdyX> Well. We closed #914897, which was… hard.
19:04:01 <marga> Yeah
19:04:04 <marga> Agreed :)
19:04:19 <marga> But we did it.  Good job everybody.  Next time please let's not have a tie :)
19:04:24 <OdyX> and you closed #911225; which makes two in a month.
19:04:33 <gwolf> (-:
19:04:36 <Mithrandir> yeah, apologies for failing to vote on 914897. :-/
19:04:53 <OdyX> I failed to ping you too. Sorry for that.
19:04:58 <marga> And gwolf closed #919951, so it's actually three in a month.
19:05:08 <OdyX> oohh
19:05:13 <marga> However, we still failed to make progress on the maint-scripts issue :-/
19:05:34 <marga> Which is actually the next topic, so let's move to that.
19:05:45 <marga> #topic #904558 What should happen when maintscripts fail to restart a service
19:06:01 <OdyX> I have two very draft mails pending for months, but it imposes me to take a half day to re-read all this and think about it.
19:06:20 <marga> two drafts about maintscripts?
19:06:40 <OdyX> nah, just to answers to various points.
19:07:34 <OdyX> So don't expect much progress.
19:08:30 <marga> Ok.  I'm a bit surprised at my lack of progress in this matter, given that this is something that I certainly care deeply about.
19:08:35 <bremner> are we deadlocked between well defined positions?
19:08:44 <marga> I suspect that I fail to find the time for it because I'm afraid of people being against me.
19:09:04 <marga> I don't think the positions are very well defined, no.
19:09:05 <OdyX> bremner: That's not my understanding no.
19:09:16 <bremner> just checking for the easy case ;)
19:10:09 <OdyX> he he
19:10:38 <Mithrandir> we've spent a lot of time debating it here before, can we look for process improvements instead of going into the matter of the discussion?
19:11:03 <marga> Like what?
19:11:15 <gwolf> marga: It's a hard-ish mail to write, so don't take it bad on yourself. Or ask for help.
19:11:22 <gwolf> As you prefer.
19:12:07 <marga> Yeah, I did ask for help, and we had said with fil that we would collaborate on this, but that didn't happen :-/
19:12:40 <Mithrandir> marga: I don't know offhand, but since the current process frustrates us, try to think of another angle of approach.
19:13:07 <gwolf> marga: oh :( Sorry, I've been too busy to really pay attention (or to offer my help!)
19:15:11 <marga> So, I think the problem that we have is that the main issue here is a design problem, and we are supposed to not do design work
19:15:40 <Mithrandir> so who is it that does this kind of design work, then?
19:15:59 <marga> Nobody?
19:16:07 <marga> I mean a random developer that feels like doing it, maybe
19:16:08 <bremner> also, we were asked, no?
19:16:09 <Mithrandir> or does it mean Somebody™ does it outside of the TC, but we don't do it inside the bug log?
19:16:25 <marga> And then they somehow they need to convince the project that it's a good idea
19:16:46 <OdyX> My understanding and practice of that constitution article is that we shall not be doing design work "as the TC"
19:17:03 <bremner> I thought we went through the meta / constitutional issues and it was OK?
19:17:06 <marga> bremner, we were asked about one thing (whether maintscripts should fail in a specific circumstance), but that led to us realizing that the problem is the whole workflow, not that single circumstance
19:17:36 <bremner> oh, the request was specific to restarting services?
19:17:49 <OdyX> We could stick to answering the question, and spawn a non-TC design group/process.
19:17:54 <marga> Yes
19:18:02 <marga> How would we do that?
19:18:30 <bremner> volunteer? send a mail to dda asking for people to join?
19:18:41 <gwolf> Right, makes sense to say "it's not what the TC can do, but we can help create the right group for that"...
19:20:49 <Mithrandir> wfm
19:21:06 <marga> But what do we do about the thing we were asked to rule on, then?
19:21:53 <Mithrandir> wait for the recommendation from the working group?
19:21:55 <gwolf> "The TC decides the problem it was asked to rule upon falls outside its boundaries of constitutional action"?
19:22:11 <OdyX> say "it's too undefined to break a tie, but we're interested to draft something"
19:22:56 <Mithrandir> gwolf: nah, we can rule on it, we just need to have some detailed designs to choose from
19:23:13 <gwolf> Right, Mithrandir makes sense
19:23:18 <gwolf> from a Special Designed Task Force!
19:24:22 <marga> Ok, so the plan is: recommend that a group is formed to work on a better solution to communicate failures to the user than failing maintscripts.  This group should present proposals and then the TC rules on which proposal to implement?
19:24:53 <OdyX> or proposes on -devel and we only chime if the consensus isn't attainable.
19:25:17 <bremner> so is this a case where we make policy ahead of practice?
19:25:57 <Mithrandir> practice is a bit all over the field, iirc?
19:26:04 <OdyX> that's my point: start by proposing something, convince the community, rule if no consensus?
19:26:15 <marga> Yeah, and the problem is that there is no better mechanism for communicating with the user
19:26:22 <marga> That's what the working group needs to deal with
19:26:28 <gwolf> Right - but we can help steer policy to an incipient but not yet established practice? :)
19:26:33 <marga> Find a better communication channel than a failing maintscript
19:27:28 <bremner> OK. Let's say the decision comes back to us if necessary, but not necessarily?
19:28:10 <gwolf> yes. I like that.
19:28:11 <marga> Yeah, that would make sense to me.
19:28:19 <gwolf> Maybe the best decision will naturally emerge
19:28:52 <Mithrandir> we're happy to bless something if that makes sense and makes it carry extra weight, though
19:29:09 <Mithrandir> so we don't end up with two competing implementations of slightly-incompatible ideas.
19:30:04 <ntyni> the original question was "does the T.C. think that Debian can be consistent on service (re)starts in maintscripts, or is the best we can do to leave it up to package maintainer discretion?"
19:30:11 <ntyni> so we could say "Debian cannot be consistent with current infrastructure but we recommend developing the infrastructure" ?
19:30:39 <marga> I like that, yes.
19:30:42 <marga> Strongly recommend
19:30:53 <Mithrandir> ok
19:31:03 <gwolf> ntyni: excelent reading/answer
19:31:12 <bremner> or at least we can't reach concensus on what should be the consistent behaviour
19:32:21 <marga> Ok, do we need to vote on this?  It seems we all basically agree
19:32:57 <bremner> since it's sortof a non-ruling, I guess we could just reply to the bug, maybe even leave it open?
19:33:53 <marga> Ok.  I'll take the AI, I think I have a clear path forward
19:34:00 <OdyX> yay
19:34:08 <gwolf> Well, we managed not to find a way out already. I think this is the right path
19:34:17 <gwolf> I mean, would be nice to have all of us say "this is right"
19:34:28 <gwolf> but I don't see any dissent. So in the worst case we have a majority
19:34:55 <marga> #action marga to send mail to the bug saying that: Debian cannot be consistent with current infrastructure but we recommend developing the infrastructure that would allow consistency, by forming a working group.
19:35:14 <ntyni> wfm fwiw
19:35:25 <marga> Alright, let's move to the item that didn't make it to the list originally.
19:35:30 <bremner> we should specifically encourage people interested in non-systemd inits to participate
19:35:37 <marga> #topic #923450 Requirements for being pre-dependency of bin:init
19:35:40 <bremner> (in the working group)
19:36:11 <marga> So, I just saw this earlier today, when I was checking the TC open bugs and it turned out that this mail had been rejected by bendel, so I forwarded it to the list
19:36:48 <OdyX> Hrm. Out of reading this right now, I don't see myself agreeing with the submitter.
19:36:51 <gwolf> I haven't yet checked it even
19:36:59 <Mithrandir> I haven't read this either
19:37:17 <OdyX> (it's short, go ahead now :-) )
19:37:22 <bremner> I think the submitter has probably behaved inappropriately. I'm not sure that's our domain.
19:37:23 <ansgar> "init" isn't essential.
19:37:34 <marga> The issue here is that the maintainers of init-system-helpers were not agreeing to put runit-init as one of the alternative pre-depends of the init meta-package
19:37:55 <gwolf> (heh, the bug even has a nice number 😉)
19:38:00 <ansgar> (Though apt will complain loudly when asked to remove "init" similar to how it complains for essential packages)
19:38:21 <marga> There's been an NMU for init-system-helpers by Dmitry Bogatov that includes the Pre-Depends in December and it hasn't been overridden.
19:38:33 <OdyX> (it was nmu'ed by KAction, the TC bug submitter)
19:38:34 <bremner> it was NACKed though
19:38:41 <OdyX> well, it's in the archive.
19:38:52 <marga> Yeah, but it was allowed to stay and get into the buster release...
19:38:57 <bremner> yes, that's the part I consider behaving badly
19:38:59 <bremner> ymmv
19:39:00 <gwolf> Uff, I think having "init-system" as a virtual package... could bring issues, to say the least...
19:39:21 <marga> Yeah, I have no idea how many things would break
19:39:47 <marga> But in any case, I think the question is valid.  Why are the maintainers of init-system-helpers the gate-keepers of alternative init systems?
19:39:58 <ansgar> marga: They aren't.
19:40:07 <OdyX> On the other hand, why not?
19:40:13 <gwolf> I am multitasking too heavily right now and cannot really comment on this...
19:41:05 <ansgar> I actually think it would be better it the "Important: yes" bit that "init" has was moved to "systemd-sysv" and similar packages.  Especially should someone decide to /not/ keep service state in sync between different init providers.
19:42:28 <Mithrandir> the question as phrased looks like detailed design, though
19:42:36 <marga> The thing that confuses me is that I expected the list of pre-depends to include upstart and openrc, but it only includes systemd-sysv, sysvinit-core and runit-init
19:42:58 <ansgar> marga: OpenRC does not provide /sbin/init.  Upstart is dead.
19:44:19 <OdyX> As things stand, it seems that enforcing a set of interfaces as "provided" by bin:init makes sense.
19:45:47 <ntyni> so aiui maintainers of init-system-helpers are currently gatekeepers for getting your own init package installable without having to answer the "do as I say!" prompt
19:46:01 <ntyni> and it doesn't seem unreasonable to me to ask for some set of rules for that
19:46:22 <Mithrandir> I agree it should be a defined set of criteria, but I also think Dmitry is behaving rudely by refusing to cancel the NMU and pulling out the TC hammer quite early on, so there are social issues at play as well.
19:46:26 <gwolf> People, I must leave at once... Sorry :(
19:46:34 <Mithrandir> gwolf: see you around
19:46:43 <gwolf> o/ !
19:46:50 <OdyX> From reading #838480, it seems that they gatekept with scrutiny and care.
19:46:52 <ntyni> (agreed on the inappropriateness of the NMU)
19:46:55 <Mithrandir> ntyni: yeah, or other workarounds when installing the system.
19:46:56 <ansgar> ntyni: Well, installable in systems that already have init installed and where the alternative conflicts with init.
19:47:44 <ntyni> OdyX: yes, I also think they seem to be doing a good job about it
19:48:11 <Mithrandir> I'm probably slightly biased since I used to maintain systemd and have worked closely with some of the current maintainers for a long time, but my impression is that the engineering done by the systemd team is not biased and the criteria used are carefully chosen.
19:48:26 <Mithrandir> (Even if not expressly enumerated)
19:48:47 <ansgar> As long as the NMU doesn't get reverted, is there a real problem?
19:49:00 <bremner> even if the maintainers are doing a bad job, we have procedures for overriding maintainers, and NMU is not it
19:49:19 <bremner> I guess I'm some kindof "maintainer fundamentalist" here.
19:49:25 <OdyX> not really no. And I really don't like setting rules for non-problems.
19:49:34 <Mithrandir> ansgar: yes, there are social bits here, and it's a bad precedent, and it means we still don't have clear criteria.
19:50:07 <marga> A clear criteria for what exactly?
19:50:09 <bremner> Mithrandir: are the social problems our problems?
19:50:29 <Mithrandir> marga: for what warrants inclusion as an alternative init system
19:50:42 <ansgar> Mithrandir: What should tech-ctte do with social problems?  Ask the maintainer to revert the NMU?  Ask the maintainer to accept the NMU (even though it wasn't reverted so far)?
19:50:43 <marga> I thought you just said above that the criteria used are carefully chosen?
19:50:58 <OdyX> I'd wouldn't want to go much further than recommending that the bin:init maintainers specify/document their requirements.
19:51:02 <Mithrandir> marga: but they're not expressed clearly.
19:51:44 <Mithrandir> bremner: hmm.  I think they maybe are, since the entire package landed at our doorstep?
19:52:30 <OdyX> well. The NMUer complains to the TC that they cannot proceed with changes; while they just did.
19:53:09 <bremner> OdyX: I think implicitly recognizing the way they proceeded was not OK
19:53:22 <OdyX> you have a point
19:53:35 <ansgar> Mithrandir: I mean, yes, there are social problems and going ahead with the NMU is not great.  But what should the ctte do about it now?
19:53:42 <marga> Alright, so I guess there's some consensus that it's ok for the init-system-helpers maintainers to be the gatekeepers, as any new init system should fulfill certain criteria, but the maintainers should better specify what this criteria is.
19:53:52 <OdyX> *could
19:54:01 <ntyni> fwiw it was an init-system-helpers maintainer (Michael Biebl) who suggested involving CTTE to define the criteria
19:54:20 <marga> Ah, but we are not asked that
19:54:47 <marga> Or well, I guess we are... I had misread that.
19:55:06 <Mithrandir> ansgar: that's the question we are being asked, by the NMUer, no less.
19:56:16 <OdyX> I'd be fine with saying "as things stand, we recognize that the bin:init maintainers are the effective gatekeeper, but it's fine as is; we just recommend that they specify their requirements better, in a README.Debian for example"
19:57:51 <ntyni> something like that would work for me I think
19:58:14 <OdyX> if they explicitely come back to us asking for the guidelines, we can help (as individuals, not as TC))
19:58:29 <bremner> well, the TC can provide advice
20:00:11 <ansgar> I think systemd-sysv had the same problem in the past:
20:00:12 <bremner> (under point 5)
20:00:22 <marga> ansgar, which problem?
20:00:31 <ansgar> you had to remove sysvinit which was essential and providing /sbin/init.
20:01:12 <marga> Ah, you mean early on
20:01:32 <ansgar> And that was actually an essential package, so apt would try to install it again, removing systemd-sysv.
20:01:38 <Mithrandir> yeah, that's how it was for wheezy and half of the jessie cycle until we switched the default, again.
20:01:46 <Mithrandir> -again
20:02:07 <marga> Oh, we are over time...
20:02:22 <marga> It seems we have a consensus as to how to move forward, though
20:02:35 <marga> Can someone take the action item to reply to this?
20:03:30 <ntyni> I suppose I can try
20:04:31 <marga> #action ntyni to reply to the reporter with the consensus obtained on IRC
20:04:36 <marga> Thanks!
20:04:48 <marga> And with that, I'll end the meeting, given that we are over time
20:04:51 <marga> #endmeeting