17:58:09 <marga> #startmeeting
17:58:09 <MeetBot> Meeting started Wed Dec 16 17:58:09 2020 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:58:14 <marga> #topic Roll Call
17:58:17 <spwhitton> Sean Whitton
17:58:23 <marga> Margarita Manterola
17:58:27 <ntyni> Niko Tyni
17:59:20 <ehashman> Elana Hashman
18:00:01 <marga> bremner mentioned that he was proctoring an exam, so I assume he won't be here. We're still missing fil, gwolf and smcv...
18:00:11 <spwhitton> Let's give them a few minutes.
18:00:16 <fil> Philip Hands
18:00:22 <marga> Yay! \o/
18:00:39 <fil> marga: nice to see you too :-)
18:01:53 <marga> Alright, let's move on to the next topic
18:02:02 <marga> #topic Review of previous meeting's AIs
18:02:08 <marga> #info http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-11-18-17.58.html
18:02:21 <spwhitton> I have done mine.
18:02:31 <marga> Well done, Sean :)
18:02:33 <spwhitton> So has gwolf and Elana w.r.t. project resources.
18:02:41 <ehashman> I did?
18:02:50 <spwhitton> Yes, you followed up to the kubernetes bug.
18:02:55 <ehashman> oh yeah?
18:02:57 <ehashman> *!
18:02:59 <ehashman> go me
18:03:17 <ehashman> I did it so long ago I forgot :D
18:03:27 <marga> :). Go you all! I'm still catching up so I don't really know who did what, but it looks like these AIs were all done. Awesome :)
18:03:33 <spwhitton> Except driving proposal #1
18:03:38 <fil> I have at least started writing something for the #2 suggestion about making it easier to consult the TC early, but I don't really know where I'm going with it, so will send an email in the next day or so for feedback
18:04:01 <marga> Sounds good.
18:04:13 <ehashman> it's true, I did not drive proposal #1, although it seems to be organically just happening?
18:04:24 <spwhitton> ehashman: it is?
18:04:38 <ehashman> iirc we got some feedback on one bug privately
18:04:54 <spwhitton> ah yes
18:05:02 <spwhitton> but we want to write it down somewhere right
18:05:05 <ehashman> yeah
18:05:07 <marga> Yeah
18:05:32 <spwhitton> maybe we want to #action fil and ehashman again
18:05:36 <ehashman> I will continue to defer that to when we are not drowning in bugs :)
18:05:46 <ehashman> but happy to be actioned again to carry forward
18:05:53 <marga> Ok
18:06:07 <marga> #action fil to send an email with what he's prepared for proposal #2 up to now
18:06:22 <marga> #action ehashman to work on proposal #1 when we are not drowning in bugs
18:06:27 <spwhitton> ahaha!
18:06:35 <marga> So, on that note...
18:06:36 <marga> #topic 971515 - kubernetes: excessive vendoring (private libraries)
18:06:46 <spwhitton> I think we should be able to get this one closed.
18:07:14 <ehashman> marga: A+
18:08:00 <marga> I still have 80+ unread emails in my TC folder, could you give a brief summary of the current status?
18:08:07 <spwhitton> No-one wants to override the maintainer.
18:08:19 <ehashman> that is a very good summary
18:08:25 <spwhitton> So, we just have to decide if there is anything useful to say.
18:08:51 <ehashman> do we have anything additional to add beyond gwolf's last summary?
18:09:07 <ehashman> link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515#107
18:09:18 <spwhitton> ehashman: only that we might want to make a shorter version of that summary and include a few additional useful points that others have made.
18:09:25 <spwhitton> as a closing statement or whatever.
18:09:40 <spwhitton> should we just assign someone to try to come up with that shortented version?  I could.
18:09:56 <ehashman> sounds like spwhitton is signing up for an #action >:)
18:10:16 <marga> Sounds good
18:10:24 <spwhitton> do we want to circulate that before sending it to -done or just send it to -done and hope for the best?
18:10:39 <ehashman> I'd appreciate reading it first but don't wanna block
18:10:43 <ansgar> The "security" argument against vendoring is probably something that is an issue the security team should raise, not other people?
18:10:48 <marga> You could write a draft and ping here for people to review
18:10:53 <spwhitton> okay
18:10:56 <ansgar> As they are the people that are most impacted.
18:11:14 <spwhitton> #action spwhitton to draft statement closing #971515
18:11:18 <ehashman> ansgar: yeah, and we solicited and received feedback from them
18:12:11 <spwhitton> I will incorporate that.
18:12:36 <marga> Good. Next bug, then?
18:12:40 <spwhitton> think so
18:12:52 <ehashman> that was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515#77 for those who don't wanna read 80+ emails
18:13:08 <fil> BTW was I right in getting the impression that kubernetes is not likely to hit stable any time soon, or am I beffuddled?  If it's not in stable, that changes the security concerns quite a bit.
18:13:22 <spwhitton> fil: I wasn't really clear on that either
18:13:31 <ehashman> fil: I think the only thing blocking it from hitting stable is this bug?
18:13:47 <ehashman> it would be included in stable in the next release
18:14:07 <ehashman> (unless it was explicitly removed/blocked from stable for release reasons)
18:14:39 <fil> Ah, in that case is a version that's N years behind what's current actually useful to the users?
18:15:14 <marga> That's kind of a generic question, isn't it?
18:15:15 <ehashman> unless we need to pull in a new version for security reasons, I imagine
18:15:23 <ehashman> yeah, that's just.. the nature of stable, hehe
18:15:32 <fil> (it would be a great shame if we got into another of these situations where upstream has a big waning about using our packges on their install page)
18:15:42 <fil> warning, even
18:15:52 <spwhitton> fil: I mean, we might, but that risk seems to be one that Janos is willing to accept.
18:16:35 <ansgar> fil: The message just linked says the package should be either kept out of stable or updated to new upstream releases (like Firefox ESR)
18:17:08 <ehashman> and I made a case that k8s is a package similar in scope/size to Firefox that might merit that special-casing
18:17:33 <ansgar> If you talk to security and/or release team and they agree with the plan to upgrade, it should be fine.
18:17:50 <ntyni> right, this is for the security and release teams to decide (rather than us)
18:17:59 <ehashman> +1
18:18:00 <fil> ansgar: either of those is better, since we otherwise just cause pain upstream when they get all the long-ago-fixed-nad-forgotten bug reports from our users
18:19:38 <marga> Alright, let's move on then, as we still have more bugs...
18:19:45 <marga> #topic 975075 - Should maintainers be able to block init compatibility changes?
18:21:15 <marga> Again, as I'm awfully behind, can anybody do a one or two line summary of where we're at with this bug?
18:21:42 <spwhitton> fil proposed a minimal compromise which was not acceptable to either side.
18:22:02 <spwhitton> The dependency issue should be resolved before the init script inclusion issue.
18:22:17 <spwhitton> Michael says he is not willing to support elogind even in the form of an alternative dependency.
18:22:44 <fil> was it really not acceptable to Matthew?  I'd say he just didn't get it becuause I was being too broad-brush about it
18:23:04 <marga> Do we know why elogind is not acceptable? Same for why the init script was dropped?
18:23:35 <fil> there's a mail on the private list about it
18:23:37 <spwhitton> not really the same, no.  it's a bit tricky to understand why not acceptable for NM.
18:24:30 <spwhitton> hmm.  I would like to dig into what is said in that e-mail but not sure I can in public IRC.
18:24:42 <ntyni> yeah that's a problem
18:24:47 * marga nods.
18:25:39 <spwhitton> I guess this is something it would be useful to have some guidelines about as part of proposal #1/
18:26:50 <marga> From my quick reading of this, it seems the reason the init script was dropped was that the dependency issue made it useless, thus fixing the dependency issue would also let the init script back in?
18:26:51 <spwhitton> ehashman: how do you deal with this sort of thing in your kubernetes work?
18:27:19 <spwhitton> marga: I think so, yes.  and smcv has already argued in public something similar.
18:27:29 <ehashman> in what way?
18:27:40 <ehashman> (this bug I am woefully behind on. trying to dig up the private mail)
18:27:58 <spwhitton> I don't mean to derail as we are talking about the bug.  but I wonder if you have ways of dealing with not knowing how to talk about private contributions in a public meeting.
18:28:59 <ansgar> spwhitton: "Discussion [...] by members of the committee, are made public"?
18:29:10 <ehashman> ah! that sort of thing. typically there's a "discuss in private, then publicize an anonymous summary"
18:29:23 <marga> Yeah, the issue is how do we discuss in public the contents of something that we received in private.
18:29:45 <spwhitton> okay.  given how important that private contribution is to the discussion we are trying to have, unclear how we can continue within this meeting.
18:30:06 <ehashman> a lot of the time the goal of discussing in private isn't to avoid having a discussion in public, but rather to refine one's reasoning and understand various arguments for and against before writing a public summary
18:30:41 <ehashman> so, I think we may need an action to summarize the content of that mail and add it to the bug?
18:30:53 <ehashman> with the consent of the maintainer, of course
18:31:46 <spwhitton> if we do that, then we probably won't get the bug resolved before the freeze
18:31:51 <spwhitton> that's quite bad for one side of the dispute.
18:32:20 <ehashman> I mean, suppose we don't; are we prepared to make a decision?
18:33:06 <spwhitton> well, this is quite tricky.  on the one hand if we did not have any time constraint then we would not consider ourselves ready to make a decision.
18:33:39 <spwhitton> on the other hand, the lack of public input from one side of the disagreement has led to the situation of a time constraint (both before and after the TC bug was filed)
18:33:48 <smcv> (gah, sorry, got absorbed in work... reading scrollback)
18:34:19 <spwhitton> one side of the dispute has been the one putting all the effort into making their case, following NMU expectations etc.
18:35:07 <spwhitton> I wonder if we could consider the possibilty of scheduling an "emergency meeting" as a way to respond to these issues?
18:35:20 <fil> the decission we'd need to be making is overriding a maintainer, thus requiring a 3:1 majority -- is that right?
18:35:28 <spwhitton> fil: yes.
18:35:49 <ehashman> oh, I just see that we only received emails on the private list from Michael today. I haven't even read them.
18:36:03 <ansgar> fil: Multiple (unnamed) maintainers :)
18:36:19 <spwhitton> I don't mean to suggest that I'm at all convicned we should override Michael.  I'm just concerned about fairness given the freeze.
18:36:37 <marga> spwhitton, how would the emergency meeting help?
18:37:10 <marga> I do think that we should try to do whatever is necessary to do the right thing. If an emergency meeting is the answer, then we can do that.
18:37:18 <spwhitton> marga: we could have a meeting which was after michael's views had been summarised and made public, but further in advance of the freeze than our next regular meeting.
18:37:21 <smcv> tbh, if team sysvinit/elogind had wanted to raise this at a time when there wasn't time pressure, they could have done so
18:37:45 <spwhitton> smcv: I was under the impression that they pretty much did but got no input from Michael.  I could well be wrong about the timeline though; can you elaborate?
18:38:12 <smcv> let me check the timeline
18:38:39 <ntyni> we got #975075 a month ago and the freeze is in less than a month from now
18:38:52 <fil> is there any chance of getting a 3:1 in favour?  (I'm not feeling it as yet, but I could imagine going for something that would give enough room for people to get on with their lives if it were obvious how to make that so)
18:39:23 <smcv> I'm certainly not getting an impression that we would want to do as the bug says
18:39:24 <ehashman> freeze policy link: https://release.debian.org/bullseye/freeze_policy.html (soft freeze is Feb. 12)
18:39:28 <spwhitton> fil: I'm the same as your parenthetical.
18:40:01 <ntyni> smcv: neither am I
18:40:19 <marga> I don't have enough information to know what I'd vote, but I kinda feel that the argument is justified.
18:40:26 <ehashman> my current feeling is that I am hesitant to override the maintainer.
18:40:27 <spwhitton> marga: which argument?
18:40:30 <smcv> 3:1 in favour of overruling to impose some compromise like the one fil suggested might be more plausible
18:41:01 <spwhitton> smcv: right.
18:41:02 <marga> Sorry, that the NMU should have been accepted. The argument would be "allow us to run our stuff".
18:41:59 <spwhitton> fil: you mentioned that you have more ideas of how to compromise beyond the ones you've written about up to now.  do you think you could explain more?  seems like it might be useful at this point.
18:42:03 <smcv> I think there is also a reasonable argument that accepting it would be accepting "make it your responsibility that our stuff doesn't regress"
18:42:47 <ehashman> as a maintainer of many things, "make it X's responsibility that X's patch doesn't cause regressions" is wishful thinking
18:42:48 <fil> it's almost a shame we got a reply, since if we hadn't I'd be arguing for an interim rulling to reverse the upsetting changes pending feedback ;-)
18:42:52 <ehashman> (in my experience)
18:42:59 * gwolf is late and on the phone...
18:43:10 <gwolf> Going quickly over backlog
18:43:24 <ehashman> unless X is already a full-fledged maintainer
18:43:27 <ehashman> and even then...
18:43:51 <marga> ehashman, but in particular regarding the init systems, this is what the GRs have been about. The package maintainers shouldn't block the work of people working on alternative init systems, even when they are not supposed to do the work.
18:44:10 <fil> spwhitton: it was mostly that if everyone had said "I can live with that" then one could tie down the responsibilities as though there were seperate packages, but actually acheived it by a well defined split of shared maintenace
18:44:25 <marga> Support can be dropped if it's broken.  But dropping support out of principle seems to go against the latest GR, FMPOV
18:44:27 <smcv> is that really what the GR concluded, though?
18:44:31 <ehashman> yes, I think we are in a position now where we are being asked to rule on applying the results of the GR
18:44:34 <fil> never mind, eh?
18:44:47 <marga> smcv, well, that's my reading at least. I just re-read it again.
18:44:49 <smcv> the winning option from the GR talks about experimenting with other init systems
18:44:49 <ansgar> marga: The GR talks about exploring alternative init systems.  I'm not sure preserving a 30-year-old system is exploration.
18:44:58 <smcv> and ... yeah, precisely what ansgar just said
18:45:12 <spwhitton> fil: well, we could enforce that on Michael if we got help defining the split from Matthew.
18:45:14 <ntyni> right, it seems controversial whether "keep sysvinit working" falls under "support experimentation of other init systems"
18:45:16 <marga> The GR talks explicitly about elogind
18:45:28 <marga> "Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian."
18:45:31 <smcv> mm
18:45:31 <ansgar> There are even things that could make it less painful (e.g. no conffiles for init scripts), but I don't thinkanything will happen there.
18:45:49 <ntyni> (sorry, was quoting from memory)
18:45:50 <ehashman> GR link: https://www.debian.org/vote/2019/vote_002#outcome
18:46:10 <smcv> which is why I mentioned on the bug the possibility of overruling Michael on the systemd/elogind dependency, but declining to overrule on restoring the init script
18:46:13 <marga> Ah, yes, sorry, should have pasted that, given that I had it open :)
18:46:21 <fil> spwhitton: I think that would only have worked if Michael were a willing participant, and had the veto power in case people got lazy about fixing init.d related bugs
18:46:42 <smcv> which would mean: well yes in principle it doesn't *need* systemd, but people wanting to run it on !systemd get to figure out how
18:47:43 <spwhitton> smcv: as you just phrased it is a nice way to interpret the GR, I think.
18:47:46 <smcv> do people think that's an option, or just nonsense?
18:47:47 <ansgar> fil: I think the endless "systemd is cancer" discussions that happen *every* time make people unwanting to interact with systemd sceptic people...
18:48:00 <marga> I'd like to see an actual reason for dropping a working init script.
18:48:04 <spwhitton> smcv: I think it's an option but Michael has ruled it out.
18:48:11 <spwhitton> (well, unless we override)
18:48:18 <ansgar> And I think Debian should eventually find some way to find a conclusion on this.  It's continuing for 6 years or so?
18:48:31 <smcv> right, it would have to be a 3:1 override if we wanted to go that way
18:48:35 <ehashman> ah, I have a question
18:49:43 <ehashman> if we choose not to override the maintainer, and leave the dependencies and removed init script as is, would that mean it is impossible to use NM with other init systems? or are there potential workarounds?
18:49:47 <smcv> it's noticeable that Sam's interpretation of the GR result (on the bug) is considerably more pro-systemd than mine
18:49:54 <fil> ansgar: quite, although there are also perfectly reasonable people that would prefer to stick to sysvinit, and giving them a place to call home doesn't seem like a terrible thing to do
18:50:20 <smcv> ehashman: I can't think of workarounds that are not based on lying to apt
18:50:31 <smcv> I mean, you could have a package with Provides: libpam-systemd
18:50:32 <spwhitton> ehashman: the init script can be worked around but not the dependency (I think if there was a workaround for that there would be no TC bug)
18:50:41 <ansgar> fil: Maybe.  It's like people demonstarting against COVID containment measures.  Some reasonable people might be under them.
18:50:44 <spwhitton> well, a non-terrible workaround :)
18:50:55 <ansgar> spwhitton: equivs? :)
18:50:55 <smcv> but then apt would let you install dbus-user-session, which absolutely can't work without systemd
18:51:11 <smcv> ansgar: please could you stop stirring?
18:51:13 <spwhitton> ansgar: that sort of comparison is not really helpful.  we are talking about serious software developers tryign to implement what they think is best.
18:51:22 <smcv> anything systemd-related is quite emotive enough already
18:51:34 <smcv> without drawing analogies to other things that people have strong feelings about
18:52:33 <smcv> if you believe one side of the already enthusiasm-draining systemd/sysvinit debate ought to win,
18:52:52 <smcv> please let it succeed on its own merits
18:53:25 <gwolf> Uff, being mostly offline for several weeks... I think I lack context too much right now to produce any real, useful input :-(
18:53:29 <ehashman> this is very tricky. I can see compelling arguments in favour of either.
18:54:46 <spwhitton> indeed.  I think we need to figure out how to create more time for ourselves.
18:55:17 <spwhitton> are we all agreed on the value of trying to make michael's contribution public in the way ehashman suggested?
18:55:24 <smcv> +1
18:55:27 <ntyni> yes
18:55:28 <marga> Alright, yes
18:56:05 <marga> Regarding "emergency meeting", wouldn't a decision taken in January be enough in regards to the freeze?
18:56:17 <ehashman> since I suggested it, I think it is fair for you to #action me with it
18:56:32 <ehashman> related to my previous #action no doubt :)
18:56:34 <smcv> one thing that occurred to me several times while responding to the bug is, should we retitle it to something that isn't a leading question?
18:56:55 <spwhitton> marga: only just.  I think we should do whatever we can to give more time given the inequality between the two sides on response rates/following NMU guidelines/etc.
18:57:20 <ehashman> marga: I think if we make a decision by the start of transitional freeze (e.g. Jan 12) that would be barely enough time, and the sooner the better
18:57:24 <fil> if there happen to be 3 of us that are strongly against overriding (which I'm not BTW, but I'm trying to optimise here) then you could kill this dead now
18:58:29 <marga> #action ehashman to summarize the contents that we received privately and get consent for publishing said summary publicly.
18:58:37 <gwolf> I will just state again, then, I don't have a fully formed position as we are... So I am not one of those possible three
18:59:13 <spwhitton> Based on my reading of this meeting so far I don't think we have three people who would not override the maintainer for any possible compromise.
18:59:15 <ehashman> I think I am strongly against Matthew's solution as it was proposed in the first comment. but if we don't solve the dependency issue, the package won't be usable outside of systemd, which would be a consideration in the context of the GR.
18:59:28 <ehashman> so I would be open to other solutions
18:59:30 <smcv> sorry, I'm leaning towards not overruling, but not strongly enough to rule out overruling on the elogind thing at least
18:59:39 <ntyni> I'm inclined not to override, at least not on the init script thing
19:00:14 <ehashman> (which may involve some overriding, and I am hopeful we could find an acceptable compromise)
19:00:46 <spwhitton> So, ehashman will seek consent.  I think we should have a plan in the cases that we do and do not get consent (including getting no reply).
19:01:01 <spwhitton> I guess we need some sort of date by which we assume we're not going to get consent?
19:01:38 <ehashman> how does a week deadline sound? I can try to get this summarized today or tomorrow in hope of publishing by the 23rd
19:01:47 <spwhitton> I think a week is reasonable.
19:01:50 <ehashman> (although, by that point, many people are shutting down until the new year)
19:01:51 <marga> And if we don't get consent?
19:02:00 <spwhitton> Well I guess either way we ned another meeting
19:02:00 <marga> It's a tricky week of the year, to be fair.
19:02:10 <gwolf> Sorry for not remembering well.. but if somebody sends ideas to the TC private alias, I would assume it's for eventual public implementation
19:02:15 <ehashman> on the other hand, Debian loves to argue on mailing lists over the holiday break :)
19:02:36 <smcv> I was about to suggest monday, to be the soonest we can while having some weekdays and some weekend in which to respond
19:02:38 <gwolf> Maybe hiding the exact why and who...
19:02:49 <smcv> but wednesday also seems fine
19:03:11 <ehashman> smcv: I'm hopeful we will get a response before Wednesday
19:03:14 <fil> we'll all be locked in isolation with nothing better to do surely? or in need of a good excuse to get away from relatives? ;-)
19:03:28 <ehashman> I'm working. yay on call ¯\_(ツ)_/¯
19:03:38 <spwhitton> do we try to discuss both possibilities now, then, or adjourn to another meeting ocne we know whether we habe consent ornot?
19:03:44 <ehashman> oof we're 5m overtime
19:03:49 <ehashman> I have a few more minutes
19:03:54 <marga> Yeah, we're overtime
19:04:00 <spwhitton> the latter, then, it would seem :)
19:04:04 <ehashman> are we okay to defer the other 2 bugs until our next meeting?
19:04:07 <spwhitton> I guess we could have a meeting two weeks from today?
19:04:17 <marga> That would be Dec 30th
19:04:21 <smcv> I can stay if there's more to discuss, even if we don't have quorum
19:04:26 <spwhitton> not a terrible day holidays-wise
19:04:29 <marga> Who could be present on the 30th? (I could)
19:04:32 <spwhitton> I could.
19:04:33 <ntyni> Dec 30th works for me
19:04:34 <smcv> I could
19:04:35 <gwolf> Dec 30 did not work well for me
19:04:39 <ehashman> 30th is doable for me
19:04:44 <ehashman> but I would prefer the week after
19:04:46 <gwolf> I travel back on the 31
19:05:14 <spwhitton> maybe we should do a poll for that
19:05:16 <ehashman> but that's 5 who could do it
19:05:19 <ehashman> +1 poll
19:05:24 * fil had his hand on the door to leave, and you drag him back to his chair -- Argh!
19:05:25 <marga> Ok, I'll take the poll action
19:05:31 <ehashman> yay marga
19:05:39 <marga> #action marga to do a poll regarding next "emergency meeting"
19:05:47 <marga> And let's close now so people can go on with their lives.
19:05:51 <spwhitton> #info likely candidates are 30th or 6th
19:05:52 <marga> #endmeeting