18:07:51 <spwhitton> #startmeeting
18:07:51 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:07:54 <spwhitton> #topic Roll Call
18:07:56 <spwhitton> Sean Whitton
18:10:12 <helmut> Helmut Grohne
18:10:25 <mjg59> Matthew Garrett
18:10:38 <smcv> Simon McVittie
18:31:00 <spwhitton> #topic Recruitment
18:31:23 <spwhitton> #action helmut to ask that one candidate about that one merged-/usr issue
18:37:46 <spwhitton> #action spwhitton to summarise some things from Jitsi to private alias for people not here
18:40:41 <spwhitton> #topic merged-/usr file movement moratorium
18:41:10 <spwhitton> So, our topic is reissuing our version of the moratorium if we think that would be helpful.
18:41:34 <spwhitton> ISTM that we should just do it.
18:41:40 <smcv> yes, I think that would be helpful
18:41:56 <helmut> 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 <mjg59> I'm not sure we have any other options at this point, sadly
18:42:10 <mjg59> Let's just rewrite dpkg in rust
18:42:11 <spwhitton> helmut: that's exactly why it seems to me we should slow things down in this wayy.
18:42:13 <smcv> 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 <spwhitton> One question then it what we say about expiry
18:42:41 <smcv> and that applies double when it's not yet clear what the long term plan *is*
18:42:53 <helmut> however, I note that basically everyone agrees that we do want to canonicalize the paths eventually
18:42:56 <spwhitton> We could make it indefinite and explicitly repeal it
18:43:19 <spwhitton> Or we could say "until consensus develops on a solution" but that might just cause more confusion.
18:43:22 <helmut> and that includes all the spectrum from Luca and Marco via Simon to Guillem
18:43:47 <smcv> honestly, explicit seems better than implicit here, and I'm regretting putting a time limit in the previous resolution
18:43:49 <spwhitton> 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 <smcv> spwhitton: yes, perfect, that
18:43:58 <helmut> my perception is that we do have consensus on that goal and the moratorium denies getting there
18:44:25 <mjg59> Perhaps make it explicit that we intend to participate in finding the solution that allows us to repeal it?
18:44:35 <mjg59> Rather than it sounding like we're just providing stop energy
18:44:35 <spwhitton> mjg59: might verge into design work.
18:44:49 <smcv> does it deny getting there? I see it as a pause not a stop, if you see what I mean
18:45:09 <spwhitton> 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 <helmut> I am with mjg59 that if we want to prolong it, we need to propose a way out
18:46:12 <spwhitton> We can refer to the work that's ongoing
18:46:20 <spwhitton> And say, "we believe this is going to bear fruit"
18:46:28 <helmut> 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 <spwhitton> helmut: you said it earlier today on -devel?
18:47:25 <helmut> like a year ago
18:47:35 <spwhitton> oh sorry I misread 'already' as 'today'
18:47:46 <spwhitton> can you summarise that idea?
18:48:27 <helmut> 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 <helmut> so the mental load for the average developer increases and that drains energy from the project
18:48:59 <spwhitton> well, we can't have either of the latter two any time soon, right?
18:49:07 <spwhitton> isn't the moratorium better than no rule at all?
18:49:32 <helmut> so while I found a lot of problems, I also found a lot of workarounds
18:50:09 <helmut> 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 <spwhitton> yes.  exactly this risk seems like reason for the moratorium.
18:50:36 <helmut> it really is not clear to me at all
18:50:40 <smcv> I agree keeping files at their "traditional" canonical paths is an extra point of complexity
18:50:53 <spwhitton> mjg59, helmut: can you think of some sample wording which addresses your concern about not providing only stop energy?
18:51:03 <spwhitton> and which doesn't go near our detailed design work restriction.
18:51:17 <smcv> 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 <mjg59> "ctte will continue to facilitate efforts to resolve this issue"?
18:51:32 <helmut> do we have a ctte meeting before the release date?
18:51:47 <spwhitton> helmut: I think they're within days of each other
18:51:52 <spwhitton> not sure which way rond.
18:51:54 <spwhitton> mjg59: LGTM
18:52:02 <spwhitton> helmut: what do you think of mjg59's wording?
18:52:37 <smcv> 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 <helmut> to me it is less about wording but about a non-trivial decision.
18:53:56 <smcv> 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 <helmut> 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 <helmut> smcv: yes
18:54:32 <helmut> about non-essential, I am less sure.
18:54:41 <spwhitton> okay I think we should have a vote with two options, one for essential, one for all
18:55:12 <helmut> 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 <mjg59> 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 <spwhitton> mjg59: voting is always e-mail
18:55:27 <smcv> do transitively essential packages count as essential in this diagram?
18:55:31 <mjg59> spwhitton: Ah apologies
18:55:35 <helmut> smcv: they do
18:55:36 <spwhitton> not at all!
18:56:00 <spwhitton> "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 <helmut> smcv: and that also means, you cannot make a package essential that has moved its files
18:56:20 <smcv> it's entirely possible to become a maintainer of a transitively essential package without knowing that has happened
18:56:49 <helmut> smcv: and that - to me - is a good reason to temporarily pass it unconditionally
18:57:14 <smcv> that also means a simpler rule to follow
18:57:20 <helmut> yes
18:57:29 <spwhitton> we are almost at time.  does anyone object to voting now?
18:57:30 <helmut> you got me convinced with arguments :)
18:57:43 <spwhitton> I'll put the transitively essential-only option on there even if no-one is going ot vote for it
18:57:57 <mjg59> I'm good with that language
18:58:00 <helmut> +1
18:58:10 <smcv> sounds good to me
18:58:12 <spwhitton> #action spwhitton to propose resoluion reinstating the moratorium along lines discussed above
18:58:17 <spwhitton> #topic Any Other Business
18:58:27 <spwhitton> I don't think there is anything else going on .. but anyone have anything?
18:58:30 <helmut> none from me
18:58:38 <helmut> who is going to hamburg?
18:58:39 <mjg59> Nope
18:58:50 <spwhitton> I am finally returning to europe at the end of this month
18:59:00 <smcv> I have one more thing I would like to say about merged /usr if that's ok
18:59:03 <spwhitton> for the first time since the end of 2019
18:59:09 <spwhitton> smcv: please go ahead
18:59:55 <smcv> 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 <spwhitton> that makes sense
19:00:17 <smcv> I think spwhitton's wording is compatible with that, so not a blocker, but I wanted to mention it
19:00:23 <smcv> notably systemd units and udev rules
19:00:51 <spwhitton> I could include mention of that if you want?
19:00:52 <smcv> possibly other "system integration glue" things outside src:systemd, like PAM
19:00:53 <helmut> smcv: +1 (though one systemd unit is affected by a diversion and thus breaks when moved)
19:01:02 <helmut> s/systemd unit/udev rule/
19:01:25 <helmut> smcv: though it adds complexity to the rule again
19:01:37 <smcv> sure, yes
19:01:48 <helmut> https://salsa.debian.org/cloud-team/amazon-ec2-utils/-/merge_requests/2
19:02:04 <smcv> 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 <spwhitton> smcv: right okay.
19:02:38 <spwhitton> okay then, I think we can close the meeting.  thank you all for your efforts.
19:02:40 <spwhitton> #endmeeting