17:58:56 <spwhitton> #startmeeting
17:58:56 <MeetBot> Meeting started Wed Nov 18 17:58:56 2020 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:58:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:02 <spwhitton> #topic Roll Call
17:59:04 <spwhitton> Sean Whitton
17:59:06 * smcv is Simon McVittie
17:59:33 * gwolf Gunnar Wolf
18:00:52 <gwolf> ... Seems like we _do_ miss the call for a meeting :-(
18:01:29 <spwhitton> Shall we postpone or does anyone have work they want to report, or someting like that?
18:02:07 * gwolf waits for somebody else to report... I only sent a mail
18:02:11 <gwolf> (and I sent it minutes ago)
18:02:13 * spwhitton is reading gwolf's mail now
18:03:42 <spwhitton> Maybe we should at least talk about recruitment.  We have exactly one candidate, right?
18:04:44 <ehashman> Elana Hashman
18:04:45 <ehashman> sorry
18:04:48 <ehashman> slow on rollcall
18:05:29 <spwhitton> Okay, let's go through our topics but perhaps not expect to achieve much.
18:05:40 <spwhitton> #topic Review of previous meeting AIs
18:05:57 <gwolf> I had one action item, which was to sum up the discussion of our last meeting
18:05:59 <spwhitton> gwolf's summary is useful.  One thing possibly missing is that I don't think any of us was really up for overriding the maintainer?
18:06:17 <gwolf> I hope you find it balanced and true to the meeting!
18:06:27 <gwolf> Right, I didn't catch that bit!
18:06:45 <spwhitton> would you like to follow up and note that, or shall someone else?
18:07:22 <ehashman> oh I am behind
18:07:35 <ehashman> I did not realize gwolf's summary went out to the bug just 30m ago, I've been on a meeting since 8am
18:08:06 <spwhitton> I read it quickly just now; the only thing which jumped out at me was that it doesn't say "it's highly unlikely we're going to vote to override the package maintainre".
18:08:15 <gwolf> ehashman: Sorry, I was late in writing it. I am happy you live in California, because 8am would mean a _very_ long meeting were you in Europe ;-)
18:09:38 <ehashman> gwolf: ha, not California, I am in the Pacific Northwest :) but yes
18:09:43 <ehashman> 4 hours of OSI today...
18:10:03 <gwolf> well, you live... in California's tz ;-)
18:10:09 <ehashman> true
18:10:20 <gwolf> The Pacific North West is somewhere like North Korea ;-)
18:10:29 <ehashman> I agree with Sean, I think we should include that none of us were interested in overriding the maintainer
18:10:43 <spwhitton> gwolf: would you like to follow up to add that yourself?  or we could action someone else.  I'd be happy to.
18:10:45 <gwolf> anyway, don't let me joke this meeting into oblivion with irrelevant issues
18:11:01 <gwolf> spwhitton: Please do! (answering to myself is not so much fun)
18:11:07 <ehashman> I also wonder if it is worth me making more explicit the scope of resources of a project like Kubernetes. Kubernetes in terms of scale and size is on-par with Debian itself (~1000 voters)
18:11:27 <spwhitton> #action spwhitton to add point about not being willing to override maintainer
18:11:34 <ehashman> that might be helpful context
18:11:38 <ehashman> spwhitton: ++
18:11:48 <gwolf> right, that could answer to what I said partially - Why should we special-case K8S (the same way we _do_ special-case Firefox, say)
18:11:52 <smcv> I think that's very relevant, yes
18:12:03 <spwhitton> #action ehashman to follow up with relative project resources info
18:12:06 <gwolf> Special-casing has its place...
18:12:13 <ehashman> should I add that in a reply to the bug report? ah great spwhitton you've tasked me :)
18:12:31 <spwhitton> ehashman: hope you do't mind a proactive #action; follow up sonuds good
18:12:41 <ehashman> all good
18:13:08 <spwhitton> the remaining action items do not seem discussable right now for different reasons
18:13:21 <spwhitton> either they're fulfilled or they're about longterm work done by someone who is not present
18:13:25 <spwhitton> so, I think we can move on
18:13:42 <spwhitton> #topic #971515 - kubernetes: excessive vendoring (private libraries)
18:13:42 <gwolf> spwhitton: Yes - but if they are not yet done, maybe they should be re-actioned?
18:13:50 <gwolf> To keep them "active"
18:14:37 <spwhitton> gwolf: I'm not sure that there is much point in reactoining "fil to drive Proposal #2" tbh but if you think helpful then please go ahead :)
18:15:14 <gwolf> Well, just to keep it as a pending point for next meeting. I'll do it.
18:15:34 <spwhitton> gwolf: okay, pobably wait until any other business given my overly eager #topic change
18:15:38 <ehashman> is the topic the ctte proposals or the bug?
18:15:40 <gwolf> OK (-:
18:15:54 <spwhitton> ehashman: topic is the bug I think.
18:16:14 <spwhitton> so, is there progress we can make on this?
18:16:31 <spwhitton> given that we have only four of us, I don't think we can decide anything, but maybe we want to discuss recent mail to the bug.
18:16:31 <ehashman> I have an action to add colour around scope of Kubernetes' size, that's some progress :)
18:16:49 <spwhitton> it sounds like the security team are okay with the package as it is.
18:16:59 <ehashman> I have been reading recent mail to the bug and I'm not sure we've learned much new? other than it sounds like "status quo" is the most maintainable for security team
18:17:00 <ehashman> yeah
18:17:16 <gwolf> yes, and that's a good data point
18:17:26 <ehashman> (this does not surprise me being familiar with k8s' release process but I'm glad they've confirmed it)
18:17:27 <spwhitton> It is unfortunate that janos has not been particpating.
18:17:34 <ehashman> should we encourage them to?
18:17:35 <gwolf> we had issues regarding vendoring both regarding security and dfsg-freeness
18:17:49 <smcv> it's sounding to me like the only options supported by people other than the bug submitter are: status quo, or don't have it in Debian?
18:17:49 <spwhitton> ehashman: I already wrote off-list asking them to participate.
18:18:13 <gwolf> if there are data points ensuring that will not be a problem in the forseeable future, we should surely include it visibly
18:18:24 <ehashman> spwhitton: did they respond?
18:18:34 <spwhitton> ehashman: no.
18:18:41 <ehashman> :nod:
18:19:38 <ehashman> one thing I am a little worried about is that, iirc, reading through the -project? or -devel? emails in March, the personal dynamic was not very good. perhaps that is discouraging Janos from participating
18:20:04 <smcv> thought experiment: suppose we had the same amount of code but it was written from scratch for k8s, not vendored
18:20:14 <smcv> would we consider that to be a dfsg problem?
18:20:17 <gwolf> ehashman: we have probably to be proactive then, and avoid interaction breakdown
18:20:26 <smcv> and would we consider that to be a security problem?
18:20:32 <smcv> I mean, a diff is a diff
18:20:40 <gwolf> ... invite somebody from CT? Or try to drive the discussion ourselves in a civil way?
18:21:31 <smcv> either the maintainer is reviewing the diff for each new upstream release, or they're trusting upstream to have done that
18:21:33 <spwhitton> smcv: presumably they'd all have the same copyright holders license, or a much smaller set, in that case.
18:21:55 <smcv> either way I don't think the fact that some of the code has its origin elsewhere really changes it
18:22:32 <spwhitton> well, it means NEW would work better.
18:22:59 <ehashman> e.g. looking at https://lists.debian.org/debian-devel/2020/03/msg00400.html
18:23:10 <ehashman> > ou are woefully inexperienced maintainer, knowing little
18:23:11 <ehashman> if anything about team work, packaging practices, their meanings and
18:23:11 <ehashman> implications. IMHO your interpretation of policy is mostly irrelevant as you
18:23:11 <ehashman> are merely trying to use the policy to justify what you did.
18:23:24 <gwolf> yes, that's one of the bits that worries me when vendoring (and I am not familiar with K8S' way in particular)
18:23:28 <ehashman> to me that reads pretty strongly as a personal attack
18:23:42 <ehashman> I am unsurprised the maintainer does not want to engage
18:24:05 <gwolf> I decided not to package Drupal8 (I was the drupal7 maintainer) because the vendored set was prone to vary with no warning to the maintainer...
18:24:21 <gwolf> ehashman: Agree with you, that's a _very_ direct attack.
18:25:29 <ehashman> maintainer posted on the bug that preceded the ctte bug that they believe Dmitry's ctte bug is "sabotage" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970717#20
18:25:47 <spwhitton> the README.source the maintainer wrote is also pretty aggressive.
18:26:25 <ehashman> so I think it's important for us to recognize that I don't think everyone involved views this as purely technical
18:26:27 <spwhitton> but not an attack.
18:26:59 <spwhitton> ehashman: well.  you're right, but given that we've decided not to override the maintainer, maybe that already disentangles us from the non-technical?
18:28:15 <ehashman> spwhitton: maybe! I'm not sure if it's worth commenting on. getting dragged to ctte seems like a pretty bad experience as a relatively new DD, and I'm not sure if that's something we should worry about
18:28:28 <ehashman> particularly if ctte is declining to override them
18:28:37 <spwhitton> yes, we should try to say something helpful.
18:28:50 <spwhitton> [ a new TC bug has just been posted! ]
18:28:59 <gwolf> :-|
18:29:17 <smcv> or it might be valuable to ask someone from the community team, who is explicitly not the one making technical decisions, to chime in
18:31:20 <spwhitton> either CT or TC saying something about the elevated tensions and the issue of a new maintainer being brought before the TC.
18:31:52 <gwolf> Yes. Do you want me to approach the CT with this issue?
18:31:52 <spwhitton> is there anything we could do to bring tensions down beyond trying to write in a compassionate way?
18:32:12 <gwolf> Or should we try to do so ourselves?
18:32:20 <ehashman> is it worth at least recognizing this dynamic explicitly?
18:32:24 <gwolf> (I'm quite time-starved, so I won't take the lead in doing so)
18:32:36 <ehashman> rather than treating this like a purely technical matter?
18:33:13 <spwhitton> that sounds like a good approach.
18:33:40 <spwhitton> any volunteers to talk to the CT other than gwolf?
18:33:51 <ehashman> I vote gwolf :)
18:34:09 * gwolf will toss the ball from TC to CT ;-)
18:34:34 <gwolf> #action gwolf will ask the CT to step in regarding some quite harsh interactions in the bug
18:34:36 <spwhitton> #agreed try to recognise/incorporate the non-technical dynamic when giving our final mostly-technical opinion on this bug
18:34:59 <spwhitton> I think this is probably enough for now; any other points on this topic?
18:35:48 <smcv> spwhitton: can I come back to your point about NEW working better?
18:35:54 <spwhitton> smcv: please do.
18:35:58 <smcv> since you are one of the people who processes it :-)
18:36:19 <smcv> when you say it would work better [if not vendoring, presumably]
18:36:40 <smcv> is the point you're making this? :
18:37:25 <smcv> vendored libs are (we assert) more likely to be under different licensing or have different authors than when large quantities of code are added to an existing project
18:38:04 <smcv> therefore it is valuable to Debian for the ftp team to be double-checking the maintainer's decision about their Freeness (or lack of)
18:38:45 <smcv> and, in particular, sufficiently valuable that the risk of blocking a k8s update because it happens to depend on a new library is considered an acceptable price to pay?
18:39:42 <spwhitton> no, I wasn't expressing an opinion on the value of NEW checking, just how easy or difficult it is for different kinds of package
18:39:53 <spwhitton> if it's all one project, and one license, then you can just list every copyright holder under `Files: *` which is a lot easier to work with than a bunge of different stanzas.
18:40:01 <smcv> oh right, I see
18:40:19 <ehashman> I would be -1 to blocking k8s (or any other package updates) with basically sticking things through NEW again on vendored dependency changes
18:40:31 <smcv> I suppose an advantage of micropackages is that it's more likely for that to genuinely happen
18:41:06 <ntyni> argh I'm off by an hour
18:41:08 <smcv> (I'm too used to e.g. gnome libraries which are large enough that there's always some little corner of the code that is differently-licensed)
18:41:09 <ntyni> sorry about that
18:41:17 <ehashman> ntyni: DST is the worst
18:41:36 <smcv> and yes I was thinking similar to ehashman
18:42:18 <smcv> if we required changes to the set of vendored dependencies to take a trip through NEW (e.g. by unvendoring them), I suspect we'd never get a timely firefox update
18:42:22 <spwhitton> I think it's fair to say that the situations which trigger something going into NEW are also designed with a different way of distributing software in mind
18:42:29 <smcv> which seems like a double standard
18:42:44 <gwolf> right - So, some packages like Firefox are granted a special-casing
18:43:06 <gwolf> And we should make explicit that whatever we decide for K8S is special-cased due to K8S' ecosystem importance
18:43:13 <gwolf> and not generalized to just any random package
18:43:42 <gwolf> it _is_ some way of a double-standard -- because we know and trust the project / the people behind Firefox (and K8S, in this case)
18:43:48 <ehashman> I think it's a combo of ecosystem importance + project scale
18:44:04 <ehashman> e.g. curl is very very important but curl development is not FF- or k8s-scale
18:44:13 <gwolf> makes sense
18:44:34 <smcv> I think it's relative impact, as well
18:45:18 <smcv> which is worse, the bugs we get from vendored libraries in k8s/firefox not necessarily having all the same updates as their unvendored equivalents, or the bugs we get by holding back updates to those packages?
18:45:55 <smcv> for firefox, not shipping security updates in a timely way certainly seems worse
18:47:08 <smcv> something I have wondered in the past when dealing with vendored libs: is there any scope for having checks on them be able to use their unvendored counterpart as a reference?
18:47:24 <smcv> like, if k8s contains libfoo 1.2.3 and libbar 2.1.0
18:47:26 <ehashman> (quick time check - do we have any other topics we need to cover today?)
18:47:38 <smcv> and Debian contains unvendored libfoo 1.2.3 and libbar 2.0.0
18:48:09 <gwolf> ehashman: There is the just-opened bug #975075, which maybe we haven't even read with our whole brain yet
18:48:19 <spwhitton> ehashman: I want to say something about the new bug.
18:48:24 <smcv> then it's sufficient to check that one libfoo is genuinely equivalent to the other, and that the diff between libbar 2.0.0 and 2.1.0 doesn't introduce anything terrible?
18:48:40 <ehashman> I haven't even read $newbug
18:48:55 <smcv> I realise the ftp team's tooling probably doesn't let them take that sort of thing into account though
18:48:58 <spwhitton> ehashman: it's procedural so it should be okay.
18:49:01 <ehashman> and from my quick skim there's a lot of reading I need to do in order to have a coherent opinion about it
18:49:27 <spwhitton> smcv: there are ways that could be done; can I suggest we chat about it after the meeting?
18:49:34 <smcv> ok
18:49:46 <smcv> happy to move on to the new bug
18:50:12 <spwhitton> #topic #975075: tech-ctte: Should maintainers be able to block init compatibility changes?
18:50:28 <spwhitton> we can't discuss the substance of this bug but I would like to discuss a procedural question
18:51:18 <spwhitton> the submitter is asking for a quick ruling because of the upcoming freeze
18:51:52 <spwhitton> without making any comment on the substance of the bug, I think that this request is reasonable given the circumstances
18:52:10 <spwhitton> i.e. we would be serving Debian better if we could be quicker than usual on this one
18:52:14 <spwhitton> is there any way we can make that happen?
18:52:19 <smcv> on one hand, yes
18:52:39 <smcv> on the other hand, it's not like the timing of the freeze wasn't foreseeable
18:52:50 <ehashman> what does "quicker than usual" mean? (as a point of reference, our next meeting is scheduled for 2020-12-16 which will be before freeze in January)
18:53:45 <spwhitton> well, are there any steps that we could take to ensure that that meeting doesn't end in "leave the bug open for discussion"?
18:53:46 <gwolf> ehashman: yes, but if we hurry in ~1mo, the maintainer will have little time to implement the changes we could mandate. Of course, the changes _could_ be forcefully included in Bullseye even if it's already frozen
18:54:17 <spwhitton> I'm not saying that I think we *must* rule quickly, just that (in contrast with e.g. the k8s bug) this is one bug where if we can it would be good
18:54:18 <gwolf> spwhitton: We should try to start discussing the bug by mail or IRC as early as we can! We don't need to wait for the next meeting
18:54:35 <gwolf> I agree we should try to be quicker...
18:54:47 <ehashman> by mail seems good, on the bug itself?
18:54:49 <spwhitton> okay.  maybe it is enough just to note that the freeze is relevant.
18:54:55 <spwhitton> ehashman: yes.
18:55:38 <smcv> on the plus side, this is a bug where the possible resolutions are pretty much "apply this patch here that is already prepared" and "decline to overrule"
18:57:34 <smcv> the patch is presumably tested and ready from the submitter's point of view (it was NMU'd, then the NMU was cancelled at the maintainer's request)
18:57:38 <spwhitton> are we: #agreed Given the upcoming freeze it would be best if we could get to a point where we can close this bug after our next meeting.
18:58:17 <smcv> so if we do what the submitter wants, applying the patch is presumably straightforward
18:58:54 <smcv> (and if it isn't, or causes regressions, reverting it is equally straightforward and the submitter gets to try to fix it)
18:59:27 <smcv> and obviously if we decline to overrule, nothing happens, which is quick :-)
19:00:50 <gwolf> So... anything else to say now on this topic?
19:01:15 <spwhitton> #agreed Given the upcoming freeze it would be best if we could advance discussion sufficiently before our next meeting that during that meeting we can come to a decision.
19:01:33 <ehashman> I think that's reasonable.
19:01:35 <spwhitton> #topic Recruitment Efforts
19:01:46 <ehashman> (I have 7 more minutes before I have to run.)
19:01:56 <spwhitton> how can we advance our recruitment efforts?
19:02:17 <spwhitton> we have a single candidate proposed by a DD, right?
19:02:37 * spwhitton doesn't know how this has gone in previous rounds so would appreciate input from more expericed CTTE members.
19:03:14 <gwolf> I also lack much insight, usually fil is our star recruiter
19:03:28 <gwolf> but we don't often get many enthusiast answers
19:03:42 <gwolf> we were lucky when both you and ehashman accepted :-]
19:03:45 <ntyni> have we asked the candidate yet if they are willing?
19:04:00 <spwhitton> I don't believe we have.
19:05:03 <ntyni> but I guess we want to have some sort of consensus first that they'd be suitable
19:05:09 <ntyni> otherwise asking them is pointless
19:05:14 <spwhitton> right.
19:05:28 <gwolf> but that discussion should happen in ctte-priv
19:05:33 <spwhitton> how about asking on the private alias for ctte membres to share their experience working with that person?
19:05:36 <spwhitton> if any.
19:05:38 <gwolf> (it just has to be kickstarted :-] )
19:05:42 <ntyni> makes sense
19:05:54 <spwhitton> #action spwhitton to follow up on private alias about present candidate.
19:06:01 <spwhitton> anything else we can do right now?
19:06:32 <ehashman> we should try to promote it more I guess
19:06:39 <spwhitton> well, we've written to d-d-a
19:06:52 <ehashman> do we have a list of desired skills for candidates?
19:07:23 <spwhitton> "instances where the nominee was able to help resolve
19:07:23 <spwhitton> disagreements, both technical and non-technical"
19:08:13 <ehashman> heh, I wonder how I qualified then :D
19:08:23 <ehashman> (joking, although idk that I have a portfolio)
19:08:59 <gwolf> ehashman: We have many eyes.
19:09:05 <ehashman> o.o
19:09:20 <gwolf> ꙭ
19:09:31 <ehashman> okay, I gotta drop nowish, anything else?
19:09:41 <spwhitton> #topic Any Other Business
19:09:43 <spwhitton> any?
19:09:53 <gwolf> I just had to re-action fil
19:09:55 <gwolf> So,
19:10:06 <gwolf> #1ction fil to drive proposal #2
19:10:11 <gwolf> #action fil to drive proposal #2
19:10:24 <ehashman> me too I think
19:10:26 <ehashman> for proposal 1
19:10:41 <gwolf> right!
19:10:51 <gwolf> #action  ehashman to drive proposal #1
19:11:14 <gwolf> (yours was an #agree last time)
19:11:21 <gwolf> that's it, I guess
19:11:48 <spwhitton> #endmeeting