17:58:18 #startmeeting 17:58:18 Meeting started Wed Dec 23 17:58:18 2020 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:25 #topic Roll Call 17:58:30 Margarita Manterola 17:58:52 Niko Tyni 17:59:15 Gunnar Wolf 17:59:47 Elana Hashman 18:00:53 :-/ I was hoping we would have quórum... 18:01:32 Sean Whitton 18:01:34 * ehashman pokes bremner fil smcv and spwhitton 18:01:41 definitely worked 18:01:49 5/8... Majority achieved! 18:01:53 ehashman: Thanks. 18:01:55 :) 18:02:18 Alright, let's do a quick review of last week's AIs. Mostly to document what gets carried over 18:02:19 I guess bremner is marking? not sure about the others 18:02:29 #topic Review of previous meetings AIs 18:02:38 #info http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-12-16-17.58.html 18:03:10 we are drowning in bugs so I don't have a writeup for my non-urgent AI 18:03:16 We did the actions that were related to this meeting, but everything else was untouched, should I just re-action people? 18:03:24 +1 18:03:36 I took mine to be due by our next regular meeting. 18:03:40 #ACTION fil to send an email with what he's prepared for proposal #2 up to now 18:03:50 #ACTION ehashman to work on proposal #1 when we are not drowning in bugs 18:04:01 #ACTION spwhitton to draft statement closing #971515 18:04:05 marga: do note that fil's term in TC is a week from finishing... 18:04:16 I don't know if he wishes to be bur 18:04:25 burdened with an ACTION just now 18:04:26 he owes it before his departure :) 18:04:30 (sorry for the typos) 18:04:42 spwhitton, yes, that's fine, it's just if I don't carry them over, then I need to check 2 logs :) 18:04:45 I think that's what the "up to now" bit covers 18:05:01 TBH, I have been too disconnected from work... am trying to get up to speed, but my brain keeps yelling ECONTEXT 18:05:03 gwolf, well, he said he had something written and the point was to send that before departing. 18:05:11 OK 18:05:25 Alright, so let's move on to the actual topic of today. 18:05:36 #topic #975075 - Should maintainers be able to block init compatibility changes? 18:05:46 * gwolf sighs 18:05:59 Someone mentioned re-titling this bug last week, but we didn't take that on. I think we should 18:06:09 marga: +100 18:06:11 Yes, retitling is IMO due 18:06:30 yes 18:06:47 How about "Should NetworkManager support elogind?" 18:07:02 sgtm 18:07:10 marga: That covers 1/3 of the request? 18:07:12 I have been mostly reading that bug. And my main thought recurs to being, if something is not broken and is not a maintenance burden, it should continue to work (that is, regarding the bit about removing the init script) 18:07:12 there's the init script issue too 18:07:18 marga: Yes IMO 18:07:46 I know there's the init script issue, but consensus here was that it was a lot less important, and that it was more an effect than a cause 18:07:56 right 18:08:11 Let's go ahead and retitle. 18:08:52 spwhitton, now? Or after the meeting? 18:09:10 Well, either. If we do it right now we don't need to action someone. Shall I? 18:09:17 Please, do, yes. 18:09:28 done 18:09:32 Tnx :) 18:10:10 Alright, so now we can concentrate on that issue. To ansgar's point, it might only be part of the request, but it's the part of the request where we might actually decide something. 18:12:54 I find myself surprisingly agreeing with the mails we received in response to the relayed summary. In particular 1) the GR was passed last year to explicitly support elogind, it seems weird to drop support for no reason 2) the bugs that were pointed out were all resolved and thus don't seem like actual good reasons. 3) There's people willing to do the work, so it's not a question of asking a maintainer to do extra work, just not block them. 18:13:12 Regarding Michael's statement, Michael's arguments against elogind were not really specifically about NM. He doesn't think using it is a great idea but did not identify why NM was burdened by enabling support. 18:14:20 And there's also Ian's mail, which I think is worth refering to - There has been an ongoing erosion suffered by all non-systemd proponents, needing them to fix what has never been broken 18:14:40 (the probable lack of NM being a symptom of it) 18:14:58 gwolf: That happens to unpopular ports too (i386 or so) 18:15:07 Or the Debian menu. 18:15:30 the winning GR option talks about exploring alternatives, not about maintaining compatibility with sysvinit 18:15:49 ansgar: But there is a GR by the whole project not giving the mandate to go 100% systemd 18:15:52 It seems there is some appetite to override the maintainer on this point, so maybe we should talk about what exactly would be required, since there are a few options. 18:16:04 But it also talks specifically about supporting elogind, which is needed for said alternatives. 18:16:11 to argue the other side, what benefit to our users does overriding the maintainer provide? the vast, vast majority of users do not use sysvinit or an alternative init system. I feel like it is detrimental to them to burn out maintainers 18:16:29 There is the patch changing the Depends: that Matthew NMUed originally, and there is fil's idea, but it wasn't clear the latter would work. 18:16:37 #link https://www.debian.org/vote/2019/vote_002#outcome 18:16:42 gwolf, that's not what the GR says. 18:17:54 like, certainly there are compelling reasons to override the maintainer. but does overriding him actually make Debian _better_? 18:18:12 My feeling (although, again, I must state that I'm short in context and have been quite disconnected for ~2wk) is that, for the bug in question, the issue is about removing working functionality, so that would not amount to maintainer burnout (but "desire to advance") 18:18:36 But, again, I will be the first to recognize I might be overlooking important bits of the situation 18:18:43 gwolf: Blocking "desire to advance" leads to burnout? :) 18:18:45 I worry exactly about the issue that ehashman brings up. We need NM to have a willing and active maintainer. Supporting elogind is too high a price to pay for burning the active maintainers. 18:18:47 this is what I'm struggling with a bit; I can see a logical argument to make an override but I'm not really sure what it accomplishes, other than maybe unblocking a very small minority of developers/end users. 18:19:18 ehashman: I mean, the GR says we want to unblock that sort of thing. 18:20:05 ehashman: I feel the same but I also think the GR means elogind support should not be blocked 18:20:23 I recognize that overriding a maintainer can always bring frustration and reduce motivation. It's a dangerous thing to do, in a way 18:20:57 I don't read "we support exploring alternatives" as "an individual maintainer can't make a call to say systemd only" 18:21:13 From my point of view, the current attitude of the maintainer is blocking the work that the GR says that the project supports. Which is wrong. However, is this "wrong" worth it? 18:21:53 it reads: It is important that the project support the efforts of developers working on such technologies ... for example by reviewing patches and participating in discussions in a timely manner. ... Packages may include support for alternate init systems besides systemd ... Maintainers use their normal procedures for deciding which patches to include. 18:22:12 packages MAY include support, not MUST 18:22:18 It's difficult to think about marga's question, because I voted for a GR option which cares more about other init systems. 18:22:22 ehashman, agreed. Still, one would expect the call is made based on actual technical reasons and not just based on disliking elogind. 18:22:38 (despite not using one) 18:22:56 ehashman: I think that an individual maintainer of a very popular package has to weigh in more things quite a bit before "calling to say systemd only". Maybe 1% of our users use sysv, but that's more than a handful of NM users for sure! 18:23:02 marga: I think there were actual technical reasons provided, and they were relatively compelling. supporting multiple init systems is multiplicatively more maintenance burden, but for a very small pool of users 18:23:23 ehashman: those were not NM-specific reasons, they were just reasons to vote the way Michael presumably did in the GR, I thought? 18:23:27 And it's different to introduce a systemd-only new package than to reduce functionality that's working well 18:23:48 ehashman, but nobody was asking him to do work, just to not block the work done by others. 18:23:59 gwolf, agreed. 18:24:01 marga+=1 18:24:32 marga: I think that's not realistic. if you require package X to support Y, as maintainer of X even if someone else offers to help with Y I'm still going to field and triage Y bugs. 18:24:41 gwolf: For systemd-shim, more people had systemd-shim installed than were using sysinit and it caused bugs then for a multiple of the sysvinit users. 18:25:18 ansgar: and why would they have it? 18:25:23 (I am mostly echoing arguments that were already made on the bug) 18:25:33 ehashman, I thought the parallel with the Finnish translation worked well here. Nobody asks the maintainer to do "work" to support the Finnish translation, only to apply the patches sent. 18:25:37 gwolf: Because we supported systemd-shim as an alternative for systemd-sysv. 18:25:49 Now, how many of these issues are sysv-specific, or would also apply to openrc users, or other systems'? 18:26:19 marga: it is much more cut and dry to determine if an issue stems from an error in the Finnish documentation than if an issue stems from subtle issues with init system integration :) 18:26:19 Ohter systems are probably at 0.01%? 18:26:44 Hmm, 0.05% maybe. 18:26:59 so I don't think it's a fair comparison 18:27:08 ehashman: I agree with your general point but there doesn't seem to be much reason to think it would apply in this case given the information we have. 18:27:18 spwhitton++ 18:27:40 To be honest I was surprised at how general Michael's reply was. 18:28:57 All the package-specific arguments are on the non-systemd side of the discussion. 18:31:20 So, the two possible overrides are "default-logind | logind" and "libpam-systemd | network-manager-nonsystemd". However there were worries the latter doesn't work. And I think I've lost track of why fil proposed the latter over the former. 18:32:42 I guess we would want to choose based on minimising effort to the NM maintainer. 18:32:50 Indeed 18:33:28 atm however I don't see why the former would be a problem for him as that was what the package had until recentlt. 18:34:07 Is this what's suggested in the policy? 18:34:41 in so far as we have a virtual package called default-logind specified in policy and that is the standard way to use a virtual package, yes 18:35:27 marga: Policy doesn't talk about that specifically I think? 18:36:01 There was a comment in March saying that it had been "seconded for inclusion in Policy" 18:36:01 I was slightly wrong about what the nm package contained, and I think I now understand a bit better. It has had libpam-systemd for 18:36:32 marga: Policy has a list of virtual packages; I think that refers to that. 18:36:38 It has had libpam-systemd for ages, before elogind existed. So the proposal to make it default-logind | logind is asking for a more substantial change than what fil proposed. 18:36:58 logind is listed as "an org.freedesktop.login1 D-Bus API implementation" and default-logind is "Debian's preferred implementation of logind, possibly architecture-specific" 18:37:03 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917431 18:37:40 It added logind to the list of virtual packages 18:38:10 do we need to design this? 18:38:17 this = the exact dependency 18:38:48 ntyni: if we think that "default-logind | logind" is a burden to the maintainer, then we have to think a bit. 18:39:06 However, we might just think that "default-logind | logind" is reasonable. 18:39:14 as opposed to saying something like "add a dependency that can be satisfied by elogind 18:39:15 atm I am not sure how it would be a burden 18:39:23 oh, or that :) 18:40:19 Yeah, I agree, we shouldn't design it... 18:41:01 So, it seems we're stuck 18:41:29 Does one line for dependency management qualify as "doing design"? 18:41:53 We just don't need to do it. That line would work, we could allow the maintainer to set a different line 18:42:02 "add a dependency that can be satisfied by elogind, such as default-logind | logind" 18:42:28 oh, rather, we want *replace* the libpam-systemd dependency with that 18:42:31 Yes, that could perfectly be an answer. 18:43:01 And an explicit dependency on systemd for using the hostnamed DBus API? /me hides. 18:44:58 oops, just realised the time -- sorry 18:45:01 aiui there's (currently) a fallback for that 18:45:19 Given that we were able to reach the maintainer privately, would it make sense to ask them privately about this? 18:45:26 marga: "this"? 18:45:47 Anyway, I'm not sure that there are only technical problems. 18:46:36 about adding the dependency that the GR says that should be supported 18:47:04 don't we already know he won't do so voluntarily? 18:47:56 BTW I'm fine with having an action, but have been failing to get to it due to having the kids in the house -- will try to sort it out tomorrow 18:48:21 spwhitton, well, I'm not sure really 18:48:59 marga: I am still reticent to override the maintainer so I suggest someone who is not me reaches out with the proposal :) 18:49:02 marga: okay, then worth asking. given how he denied the NMU, closed the bug etc. I don't see how we'll get a different answer, but if there is time, we can ask. 18:49:25 spwhitton: there was no technical reason for my made-up dependency thing -- it was just an attept to see if there was a split of responsibility that everyone could agree to in the hope that we could sort out the technical details later 18:49:26 spwhitton: We can assume there is time 18:49:33 (mostly on the basis of "the cost of doing so seems to outweigh the benefits") 18:49:57 Alright, I can volunteer to write up something and send it privately 18:49:58 I mean - Even with the freeze looming, if there is an upload implementing a TC ruling, I have high expectations that the release team would accept it 18:50:41 I was really trying to come up with a way of saying that we can dump all the details (and possibly the init script etc.) in some little glue package 18:50:45 gwolf: For new features? (NM in buster didn't support elogind either and depended on libpam-systemd.) 18:50:59 ... but the mail communication *should* have a deadline, past which it would require us to take action 18:51:07 deadline one week? 18:51:09 ansgar: I expect so, yes. 18:51:17 If the reply is that they won't do it... Should we carry out a vote? 18:51:49 well either we discuss at our next regular meeting or we vote before then 18:51:49 probably for the best 18:52:01 fwiw we were also asked to override the maintainer to restore the init script, and I'm not prepared to do that 18:52:13 given the time constraints, I think we should vote before the next meeting 18:52:14 marga: I think it could be carried out in parallel... Maybe we could vote in the private alias (with the obligation to later make the vote public) to gain us some time? 18:52:28 ntyni, right, I think we already discussed that we wouldn't do that. 18:52:37 okay, wasn't clear to me 18:52:38 gwolf, uhm, I'd rather not. 18:52:56 marga: OK - As the Chair, it's your call. 18:53:24 marga: when could you get the e-mail to Michael sent by? 18:53:26 I would like to get the issue sorted before our next meeting as well... 18:53:26 personally, I don't see how the TC canb put up with people failing to engage with it's processes so thouroughly, and letting them get away with it -- it's a disasterous precident -- but then again, I'm not going to have to deal with the aftermath either way ;-) 18:53:51 I agree with fil in general. 18:53:54 fil: Because it's tiring to deal with the tech-ctte again and again? 18:53:55 * gwolf votes to rename fil and invite him for a new TC tenure ;-) 18:54:20 fil: There were mutliple tech-ctte cases for NM, for systemd, ... 18:54:57 spwhitton, tomorrow 18:55:23 marga: coolio, then we can start a vote if no positive resopnse on the 30th, say? 18:55:30 #action marga to send email to the maintainer trying to see if we can get them to agree to include logind support. 18:55:34 ansgar: yeah, but there were also several polite requests from the TC which didn't even get a "leave me alone!" -- how are the TC supposed to do their job? 18:55:36 spwhitton, sure. 18:55:52 we should action someone to do that probably 18:56:09 fil: I'm fairly sure I heard people say they don't have the energy to deal with the TC before... 18:56:29 I can empathize 18:56:32 fil: want to start the vote on your way out the door? :) 18:56:39 I don't have energy to deal with me half the time either ;) 18:57:09 spwhitton: I have broad shoulders, I'm happy to take the blme :-) 18:57:14 ehashman: I at least hope you agree with yourself a majority of the time... 18:57:17 Alright, then 18:57:24 gwolf: LOL 18:57:26 Totally unrelated, I'm tempted to open a tech-ctte bug too ;-) 18:57:35 #action fil to start a vote by Dec 30th if we don't get somo non-voting agreement. 18:57:58 Thanks fil! 18:58:00 lol 18:58:13 :) 18:58:15 action accepted 18:58:17 *hugs* 18:58:24 :-D 18:58:33 so I guess fil will have a vote even if we aren't finished by Dec 31st? 18:58:35 And this is on "replace libpam-systemd dep with a dep staisfiable by elogind, such as default-logind | logind", *not* init scripts 18:58:38 (do I get to vote?) 18:58:48 spwhitton, indeed 18:59:01 fil: If the vote is started before Jan 1, you can vote 18:59:04 fil, you get to vote as long as you do it before jan 1st, I think :) 18:59:12 (I cannot ensure your vote will be counted... ;-) ) 18:59:17 We are at time and I think we have actions. So we can all move on with our lives? 18:59:22 I think so. 18:59:24 thanks all 18:59:25 probably best if I don't though -- seems a bit like tossing a molotov over my shoulder on the way out ;-) 18:59:39 it has an effect on the majority requirements too 18:59:42 fil: I disagree as more voters means more legitimacy 18:59:44 I suppose 18:59:54 (typically) 19:00:10 You avoid all problems if the result is fixed before Jan 1st :> 19:00:17 heh 19:00:21 I am working next week! 19:00:21 ansgar: That's true. 19:00:28 Alright, let's finish this 19:00:32 #endmeeting