17:58:18 <marga> #startmeeting
17:58:18 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:58:25 <marga> #topic Roll Call
17:58:30 <marga> Margarita Manterola
17:58:52 <ntyni> Niko Tyni
17:59:15 <gwolf> Gunnar Wolf
17:59:47 <ehashman> Elana Hashman
18:00:53 <marga> :-/ I was hoping we would have quórum...
18:01:32 <spwhitton> Sean Whitton
18:01:34 * ehashman pokes bremner fil smcv and spwhitton
18:01:41 <ehashman> definitely worked
18:01:49 <gwolf> 5/8... Majority achieved!
18:01:53 <gwolf> ehashman: Thanks.
18:01:55 <marga> :)
18:02:18 <marga> Alright, let's do a quick review of last week's AIs. Mostly to document what gets carried over
18:02:19 <ehashman> I guess bremner is marking? not sure about the others
18:02:29 <marga> #topic Review of previous meetings AIs
18:02:38 <marga> #info http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-12-16-17.58.html
18:03:10 <ehashman> we are drowning in bugs so I don't have a writeup for my non-urgent AI
18:03:16 <marga> We did the actions that were related to this meeting, but everything else was untouched, should I just re-action people?
18:03:24 <ehashman> +1
18:03:36 <spwhitton> I took mine to be due by our next regular meeting.
18:03:40 <marga> #ACTION fil to send an email with what he's prepared for proposal #2 up to now
18:03:50 <marga> #ACTION ehashman to work on proposal #1 when we are not drowning in bugs
18:04:01 <marga> #ACTION spwhitton to draft statement closing #971515
18:04:05 <gwolf> marga: do note that fil's term in TC is a week from finishing...
18:04:16 <gwolf> I don't know if he wishes to be bur
18:04:25 <gwolf> burdened with an ACTION just now
18:04:26 <ehashman> he owes it before his departure :)
18:04:30 <gwolf> (sorry for the typos)
18:04:42 <marga> 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 <ehashman> I think that's what the "up to now" bit covers
18:05:01 <gwolf> TBH, I have been too disconnected from work... am trying to get up to speed, but my brain keeps yelling ECONTEXT
18:05:03 <marga> gwolf, well, he said he had something written and the point was to send that before departing.
18:05:11 <gwolf> OK
18:05:25 <marga> Alright, so let's move on to the actual topic of today.
18:05:36 <marga> #topic #975075 - Should maintainers be able to block init compatibility changes?
18:05:46 * gwolf sighs
18:05:59 <marga> Someone mentioned re-titling this bug last week, but we didn't take that on. I think we should
18:06:09 <ehashman> marga: +100
18:06:11 <gwolf> Yes, retitling is IMO due
18:06:30 <ntyni> yes
18:06:47 <marga> How about "Should NetworkManager support elogind?"
18:07:02 <ehashman> sgtm
18:07:10 <ansgar> marga: That covers 1/3 of the request?
18:07:12 <gwolf> 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 <ntyni> there's the init script issue too
18:07:18 <gwolf> marga: Yes IMO
18:07:46 <marga> 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 <gwolf> right
18:08:11 <spwhitton> Let's go ahead and retitle.
18:08:52 <marga> spwhitton, now? Or after the meeting?
18:09:10 <spwhitton> Well, either.  If we do it right now we don't need to action someone.  Shall I?
18:09:17 <marga> Please, do, yes.
18:09:28 <spwhitton> done
18:09:32 <marga> Tnx :)
18:10:10 <marga> 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 <marga> 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 <spwhitton> 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 <gwolf> 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 <gwolf> (the probable lack of NM being a symptom of it)
18:14:58 <ansgar> gwolf: That happens to unpopular ports too (i386 or so)
18:15:07 <ansgar> Or the Debian menu.
18:15:30 <ntyni> the winning GR option talks about exploring alternatives, not about maintaining compatibility with sysvinit
18:15:49 <gwolf> ansgar: But there is a GR by the whole project not giving the mandate to go 100% systemd
18:15:52 <spwhitton> 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 <marga> But it also talks specifically about supporting elogind, which is needed for said alternatives.
18:16:11 <ehashman> 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 <spwhitton> 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 <marga> #link https://www.debian.org/vote/2019/vote_002#outcome
18:16:42 <marga> gwolf, that's not what the GR says.
18:17:54 <ehashman> like, certainly there are compelling reasons to override the maintainer. but does overriding him actually make Debian _better_?
18:18:12 <gwolf> 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 <gwolf> But, again, I will be the first to recognize I might be overlooking important bits of the situation
18:18:43 <ansgar> gwolf: Blocking "desire to advance" leads to burnout? :)
18:18:45 <marga> 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 <ehashman> 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 <spwhitton> ehashman: I mean, the GR says we want to unblock that sort of thing.
18:20:05 <ntyni> ehashman: I feel the same but I also think the GR means elogind support should not be blocked
18:20:23 <gwolf> 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 <ehashman> I don't read "we support exploring alternatives" as "an individual maintainer can't make a call to say systemd only"
18:21:13 <marga> 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 <ehashman> 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 <ehashman> packages MAY include support, not MUST
18:22:18 <spwhitton> 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 <marga> 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 <spwhitton> (despite not using one)
18:22:56 <gwolf> 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 <ehashman> 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 <spwhitton> 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 <gwolf> And it's different to introduce a systemd-only new package than to reduce functionality that's working well
18:23:48 <marga> ehashman, but nobody was asking him to do work, just to not block the work done by others.
18:23:59 <marga> gwolf, agreed.
18:24:01 <gwolf> marga+=1
18:24:32 <ehashman> 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 <ansgar> 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 <gwolf> ansgar: and why would they have it?
18:25:23 <ehashman> (I am mostly echoing arguments that were already made on the bug)
18:25:33 <marga> 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 <ansgar> gwolf: Because we supported systemd-shim as an alternative for systemd-sysv.
18:25:49 <gwolf> Now, how many of these issues are sysv-specific, or would also apply to openrc users, or other systems'?
18:26:19 <ehashman> 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 <ansgar> Ohter systems are probably at 0.01%?
18:26:44 <ansgar> Hmm, 0.05% maybe.
18:26:59 <ehashman> so I don't think it's a fair comparison
18:27:08 <spwhitton> 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 <marga> spwhitton++
18:27:40 <spwhitton> To be honest I was surprised at how general Michael's reply was.
18:28:57 <spwhitton> All the package-specific arguments are on the non-systemd side of the discussion.
18:31:20 <spwhitton> 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 <spwhitton> I guess we would want to choose based on minimising effort to the NM maintainer.
18:32:50 <marga> Indeed
18:33:28 <spwhitton> 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 <marga> Is this what's suggested in the policy?
18:34:41 <spwhitton> 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 <ansgar> marga: Policy doesn't talk about that specifically I think?
18:36:01 <marga> There was a comment in March saying that it had been "seconded for inclusion in Policy"
18:36:01 <spwhitton> 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 <ansgar> marga: Policy has a list of virtual packages; I think that refers to that.
18:36:38 <spwhitton> 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 <ntyni> 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 <marga> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917431
18:37:40 <marga> It added logind to the list of virtual packages
18:38:10 <ntyni> do we need to design this?
18:38:17 <ntyni> this = the exact dependency
18:38:48 <spwhitton> ntyni: if we think that "default-logind | logind" is a burden to the maintainer, then we have to think a bit.
18:39:06 <spwhitton> However, we might just think that "default-logind | logind" is reasonable.
18:39:14 <ntyni> as opposed to saying something like "add a dependency that can be satisfied by elogind
18:39:15 <spwhitton> atm I am not sure how it would be a burden
18:39:23 <spwhitton> oh, or that :)
18:40:19 <marga> Yeah, I agree, we shouldn't design it...
18:41:01 <marga> So, it seems we're stuck
18:41:29 <gwolf> Does one line for dependency management qualify as "doing design"?
18:41:53 <marga> 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 <spwhitton> "add a dependency that can be satisfied by elogind, such as default-logind | logind"
18:42:28 <spwhitton> oh, rather, we want *replace* the libpam-systemd dependency with that
18:42:31 <gwolf> Yes, that could perfectly be an answer.
18:43:01 <ansgar> And an explicit dependency on systemd for using the hostnamed DBus API? /me hides.
18:44:58 <fil> oops, just realised the time -- sorry
18:45:01 <ntyni> aiui there's (currently) a fallback for that
18:45:19 <marga> Given that we were able to reach the maintainer privately, would it make sense to ask them privately about this?
18:45:26 <spwhitton> marga: "this"?
18:45:47 <ansgar> Anyway, I'm not sure that there are only technical problems.
18:46:36 <marga> about adding the dependency that the GR says that should be supported
18:47:04 <spwhitton> don't we already know he won't do so voluntarily?
18:47:56 <fil> 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 <marga> spwhitton, well, I'm not sure really
18:48:59 <ehashman> 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 <spwhitton> 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 <fil> 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 <gwolf> spwhitton: We can assume there is time
18:49:33 <ehashman> (mostly on the basis of "the cost of doing so seems to outweigh the benefits")
18:49:57 <marga> Alright, I can volunteer to write up something and send it privately
18:49:58 <gwolf> 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 <fil> 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 <ansgar> gwolf: For new features?  (NM in buster didn't support elogind either and depended on libpam-systemd.)
18:50:59 <gwolf> ... but the mail communication *should* have a deadline, past which it would require us to take action
18:51:07 <spwhitton> deadline one week?
18:51:09 <gwolf> ansgar: I expect so, yes.
18:51:17 <marga> If the reply is that they won't do it... Should we carry out a vote?
18:51:49 <spwhitton> well either we discuss at our next regular meeting or we vote before then
18:51:49 <ehashman> probably for the best
18:52:01 <ntyni> 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 <ehashman> given the time constraints, I think we should vote before the next meeting
18:52:14 <gwolf> 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 <marga> ntyni, right, I think we already discussed that we wouldn't do that.
18:52:37 <ntyni> okay, wasn't clear to me
18:52:38 <marga> gwolf, uhm, I'd rather not.
18:52:56 <gwolf> marga: OK - As the Chair, it's your call.
18:53:24 <spwhitton> marga: when could you get the e-mail to Michael sent by?
18:53:26 <gwolf> I would like to get the issue sorted before our next meeting as well...
18:53:26 <fil> 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 <spwhitton> I agree with fil in general.
18:53:54 <ansgar> 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 <ansgar> fil: There were mutliple tech-ctte cases for NM, for systemd, ...
18:54:57 <marga> spwhitton, tomorrow
18:55:23 <spwhitton> marga: coolio, then we can start a vote if no positive resopnse on the 30th, say?
18:55:30 <marga> #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 <fil> 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 <marga> spwhitton, sure.
18:55:52 <spwhitton> we should action someone to do that probably
18:56:09 <ansgar> fil: I'm fairly sure I heard people say they don't have the energy to deal with the TC before...
18:56:29 <ehashman> I can empathize
18:56:32 <spwhitton> fil: want to start the vote on your way out the door? :)
18:56:39 <ehashman> I don't have energy to deal with me half the time either ;)
18:57:09 <fil> spwhitton: I have broad shoulders, I'm happy to take the blme :-)
18:57:14 <gwolf> ehashman: I at least hope you agree with yourself a majority of the time...
18:57:17 <marga> Alright, then
18:57:24 <ehashman> gwolf: LOL
18:57:26 <ansgar> Totally unrelated, I'm tempted to open a tech-ctte bug too ;-)
18:57:35 <marga> #action fil to start a vote by Dec 30th if we don't get somo non-voting agreement.
18:57:58 <marga> Thanks fil!
18:58:00 <fil> lol
18:58:13 <marga> :)
18:58:15 <fil> action accepted
18:58:17 <marga> *hugs*
18:58:24 <gwolf> :-D
18:58:33 <ntyni> so I guess fil will have a vote even if we aren't finished by Dec 31st?
18:58:35 <spwhitton> 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 <fil> (do I get to vote?)
18:58:48 <marga> spwhitton, indeed
18:59:01 <gwolf> fil: If the vote is started before Jan 1, you can vote
18:59:04 <marga> fil, you get to vote as long as you do it before jan 1st, I think :)
18:59:12 <gwolf> (I cannot ensure your vote will be counted... ;-) )
18:59:17 <marga> We are at time and I think we have actions. So we can all move on with our lives?
18:59:22 <spwhitton> I think so.
18:59:24 <spwhitton> thanks all
18:59:25 <fil> probably best if I don't though -- seems a bit like tossing a molotov over my shoulder on the way out ;-)
18:59:39 <ntyni> it has an effect on the majority requirements too
18:59:42 <spwhitton> fil: I disagree as more voters means more legitimacy
18:59:44 <ntyni> I suppose
18:59:54 <spwhitton> (typically)
19:00:10 <ansgar> You avoid all problems if the result is fixed before Jan 1st :>
19:00:17 <ehashman> heh
19:00:21 <ehashman> I am working next week!
19:00:21 <gwolf> ansgar: That's true.
19:00:28 <marga> Alright, let's finish this
19:00:32 <marga> #endmeeting