18:07:51 #startmeeting 18:07:51 Meeting started Tue May 9 18:07:51 2023 UTC. The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:07:51 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:07:54 #topic Roll Call 18:07:56 Sean Whitton 18:10:12 Helmut Grohne 18:10:25 Matthew Garrett 18:10:38 Simon McVittie 18:31:00 #topic Recruitment 18:31:23 #action helmut to ask that one candidate about that one merged-/usr issue 18:37:46 #action spwhitton to summarise some things from Jitsi to private alias for people not here 18:40:41 #topic merged-/usr file movement moratorium 18:41:10 So, our topic is reissuing our version of the moratorium if we think that would be helpful. 18:41:34 ISTM that we should just do it. 18:41:40 yes, I think that would be helpful 18:41:56 I feel a bit lost in detail about this. There's just so many moving parts and whenever I come up with something that looks like a way forward at least three non-trivial consequences pop up 18:41:57 I'm not sure we have any other options at this point, sadly 18:42:10 Let's just rewrite dpkg in rust 18:42:11 helmut: that's exactly why it seems to me we should slow things down in this wayy. 18:42:13 when the floodgates open after the bookworm release, I don't want people uploading well-intentioned changes that accidentally sabotage a long term plan 18:42:35 One question then it what we say about expiry 18:42:41 and that applies double when it's not yet clear what the long term plan *is* 18:42:53 however, I note that basically everyone agrees that we do want to canonicalize the paths eventually 18:42:56 We could make it indefinite and explicitly repeal it 18:43:19 Or we could say "until consensus develops on a solution" but that might just cause more confusion. 18:43:22 and that includes all the spectrum from Luca and Marco via Simon to Guillem 18:43:47 honestly, explicit seems better than implicit here, and I'm regretting putting a time limit in the previous resolution 18:43:49 I would be inclined to make it indefinite but say that we expect to repeal it at some point during the upcoming development cycle, as early as we can 18:43:57 spwhitton: yes, perfect, that 18:43:58 my perception is that we do have consensus on that goal and the moratorium denies getting there 18:44:25 Perhaps make it explicit that we intend to participate in finding the solution that allows us to repeal it? 18:44:35 Rather than it sounding like we're just providing stop energy 18:44:35 mjg59: might verge into design work. 18:44:49 does it deny getting there? I see it as a pause not a stop, if you see what I mean 18:45:09 helmut: hrm. once you tell your fellow TC members, some time later this year, "I understand all the parts now and am confident in my/[someone's] solution XYZ, we will immediately vote to undo it. 18:45:51 I am with mjg59 that if we want to prolong it, we need to propose a way out 18:46:12 We can refer to the work that's ongoing 18:46:20 And say, "we believe this is going to bear fruit" 18:46:28 I said it earlier already that I think for the average developer the moratorium is worse than both fully converted and fully unconverted 18:47:17 helmut: you said it earlier today on -devel? 18:47:25 like a year ago 18:47:35 oh sorry I misread 'already' as 'today' 18:47:46 can you summarise that idea? 18:48:27 the moratorium bears complexity. a non-trivial rule to follow. having a fully merged system is easier to work with as is a fully unmerged system 18:48:51 so the mental load for the average developer increases and that drains energy from the project 18:48:59 well, we can't have either of the latter two any time soon, right? 18:49:07 isn't the moratorium better than no rule at all? 18:49:32 so while I found a lot of problems, I also found a lot of workarounds 18:50:09 it could be that we find solutions to problems as we go, but it could also be that at some point we paint us in a dark corner where we have to decide to either break upgrades from testing to unstable or to break upgrades from stable to nextstable 18:50:35 yes. exactly this risk seems like reason for the moratorium. 18:50:36 it really is not clear to me at all 18:50:40 I agree keeping files at their "traditional" canonical paths is an extra point of complexity 18:50:53 mjg59, helmut: can you think of some sample wording which addresses your concern about not providing only stop energy? 18:51:03 and which doesn't go near our detailed design work restriction. 18:51:17 and in practice it keeps one of the down sides of unmerged /usr: you have to "just know" that it's /bin/kill but /usr/bin/top 18:51:23 "ctte will continue to facilitate efforts to resolve this issue"? 18:51:32 do we have a ctte meeting before the release date? 18:51:47 helmut: I think they're within days of each other 18:51:52 not sure which way rond. 18:51:54 mjg59: LGTM 18:52:02 helmut: what do you think of mjg59's wording? 18:52:37 but my concern (and I thought helmut's as well, but maybe not) is that if we let individual package maintainers unilaterally start migrating files across the /usr boundary, like say /bin/kill => /usr/bin/kill, then that will unintentionally make it harder to solve this "cleanly" by whatever route we end up with 18:52:43 to me it is less about wording but about a non-trivial decision. 18:53:56 I had understood from recent -devel that e.g. Luca wanted to start doing those migrations when trixie opens, and that helmut was saying "wait, not yet, we're not ready". was that a wrong understanding? 18:54:05 I think from the current discussion point, I actually prefer keeping the moratorium for essential packages, because the risk is very high there and because changing essential almost certainly breaks the bootstrap protocol 18:54:24 smcv: yes 18:54:32 about non-essential, I am less sure. 18:54:41 okay I think we should have a vote with two options, one for essential, one for all 18:55:12 are we sure that the cost of the moratorium to the project strikes a good balance to the risk involved for non-essential packages? 18:55:16 If we're going to vote I think we might want to wait until the next meeting, or do that via email in a couple of weeks? 18:55:26 mjg59: voting is always e-mail 18:55:27 do transitively essential packages count as essential in this diagram? 18:55:31 spwhitton: Ah apologies 18:55:35 smcv: they do 18:55:36 not at all! 18:56:00 "The Technical Committee reinstates its advice that [copy from old resolution]. This moratorium lasts until we repeal it. We expect to do that during the trixie development cycle, sooner rather than later, and we will continue to facilitate efforts to resolve the remaining issues." 18:56:00 smcv: and that also means, you cannot make a package essential that has moved its files 18:56:20 it's entirely possible to become a maintainer of a transitively essential package without knowing that has happened 18:56:49 smcv: and that - to me - is a good reason to temporarily pass it unconditionally 18:57:14 that also means a simpler rule to follow 18:57:20 yes 18:57:29 we are almost at time. does anyone object to voting now? 18:57:30 you got me convinced with arguments :) 18:57:43 I'll put the transitively essential-only option on there even if no-one is going ot vote for it 18:57:57 I'm good with that language 18:58:00 +1 18:58:10 sounds good to me 18:58:12 #action spwhitton to propose resoluion reinstating the moratorium along lines discussed above 18:58:17 #topic Any Other Business 18:58:27 I don't think there is anything else going on .. but anyone have anything? 18:58:30 none from me 18:58:38 who is going to hamburg? 18:58:39 Nope 18:58:50 I am finally returning to europe at the end of this month 18:59:00 I have one more thing I would like to say about merged /usr if that's ok 18:59:03 for the first time since the end of 2019 18:59:09 smcv: please go ahead 18:59:55 I think a possible route we should bear in mind is that we might want to partially lift the moratorium for categories of files, rather than categories of packages 19:00:12 that makes sense 19:00:17 I think spwhitton's wording is compatible with that, so not a blocker, but I wanted to mention it 19:00:23 notably systemd units and udev rules 19:00:51 I could include mention of that if you want? 19:00:52 possibly other "system integration glue" things outside src:systemd, like PAM 19:00:53 smcv: +1 (though one systemd unit is affected by a diversion and thus breaks when moved) 19:01:02 s/systemd unit/udev rule/ 19:01:25 smcv: though it adds complexity to the rule again 19:01:37 sure, yes 19:01:48 https://salsa.debian.org/cloud-team/amazon-ec2-utils/-/merge_requests/2 19:02:04 and I think in answer to spwhitton, adding complexity to the rule is a reason to not mention that in our resolution now 19:02:22 smcv: right okay. 19:02:38 okay then, I think we can close the meeting. thank you all for your efforts. 19:02:40 #endmeeting