17:59:54 <spwhitton> #startmeeting
17:59:54 <MeetBot> Meeting started Wed Sep  8 17:59:54 2021 UTC.  The chair is spwhitton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:54 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:58 <spwhitton> #topic Roll Call
17:59:59 <spwhitton> Sean Whitton
18:00:33 <ehashman> good morning
18:00:34 <ehashman> Elana Hashman
18:00:34 <marga> Margarita Manterola
18:00:35 <Myon> Christoph Berg
18:00:41 <marga> (I'm at a beergarden with other Debian ppl)
18:00:44 <bremner> David Bremner
18:00:49 <bremner> marga: great!
18:00:50 <spwhitton> marga: oh how nice :)
18:01:15 <Myon> so we have extra audience!
18:01:26 <spwhitton> they should all join the channel
18:02:01 <smcv> Simon McVittie
18:02:01 <marga> We are not doing jitsi, right?
18:02:17 <spwhitton> marga: a few of us reported having issues so I suggested postponing trying that.
18:02:31 <spwhitton> ntyni: around?
18:02:32 <marga> Cool, yes. Next time.
18:02:37 <spwhitton> I'd ping gwolf but he is not in this channel.
18:02:53 <ehashman> he has left us :'(
18:03:10 * spwhitton /invites
18:03:38 <marga> Maybe because of not being identified. It happens to me when I reconnect and my client fails to ident
18:03:49 <bremner> gwolf is mad at me for skipping debconf
18:03:50 <spwhitton> I'd set this channel -R but I don't think I have ops
18:04:18 <spwhitton> oh ho ho
18:04:34 * ehashman trembles before marga's immense power
18:04:55 <marga> If only I remembered how to use it :)
18:05:00 <spwhitton> /mode -Ro marga
18:06:09 <spwhitton> alright, I'm gonna move us on to our agenda topics
18:06:11 <marga> I tried to add you folks to the access list, but I'm only CHANOP, not master.
18:06:12 <spwhitton> thanks for fixing that marga
18:06:28 <spwhitton> #topic Finalising private communication proposal
18:06:43 <spwhitton> #link https://pad.dc21.debconf.org/p/11-what-is-your-technical-committee-up-to-now
18:07:13 <spwhitton> I think we want to move the text from the slides into our procedures/ dir in our repo?
18:07:22 <spwhitton> and once we've done that for both proposals, perhaps a brief note to d-d-a?
18:07:42 <ehashman> seems reasonable to me
18:07:45 <Myon> ack
18:07:55 <marga> +1
18:08:06 <spwhitton> well if the person with '@' in front of her name says +1 then we're good
18:08:22 <marga> Oops, sorry.
18:08:28 <spwhitton> ;)
18:08:30 <spwhitton> anyone like to be assigned to transfer to markdown?
18:08:52 <bremner> I can do it if no one else volunteers
18:09:01 <bremner> It would be good for me to re-engage with that proposal
18:09:10 <spwhitton> great.  I don't believe there are any additional notes on that one beyond what's in the slides -- right?
18:09:28 <Myon> did we get any feedback on the proposals?
18:09:43 <spwhitton> Myon: yes, but the only thing that's written down is on early invocation, loooking at the pad anyway.
18:09:48 <spwhitton> but maybe someone else has personal notes?
18:09:56 <Myon> ah on the pad
18:10:14 <marga> I don't think we had any comments on process, no.
18:11:27 <spwhitton> alrighty
18:11:45 <spwhitton> #action bremner to commit final version of early invocation to tech-ctte.git procedures/
18:11:52 <spwhitton> thanks for volunteering
18:12:08 <spwhitton> #topic Finalising early invocation proposal
18:12:38 <spwhitton> For this one there were a few additional notes.  I think they're allt hings we agree on, though?  such that while converting it to md will be more work than the other proposal, there isn't anything to resolve by discussion?
18:12:42 <spwhitton> please correct me if I'm wrong
18:14:06 <marga> Yeah, the main comment was that the "facilitator" should consider whether they should recuse themselves, right?
18:14:18 <marga> But it's just a guideline and not a must
18:14:22 <spwhitton> that they should explicitly ask themselves that question
18:14:31 <spwhitton> but that it's up to them whether to do it
18:14:36 <marga> Yup
18:14:46 <spwhitton> and also to write down that facilitator certainly never does more than TC, in particular detailed design work
18:15:00 <spwhitton> anyone up for writing this up?
18:15:14 <spwhitton> it should be straightforward but more time consuming as there are a number of slides to condense down
18:15:56 <smcv> does this imply if there is a facilitator, it has to be someone who specifically doesn't have opinions on the issue / isn't trying to help to solve it?
18:16:29 <spwhitton> smcv: no.  I think the point was at the point at which a TC bug is filed they shoudl ask whether they have too much become that
18:16:31 <smcv> (because that would often be detailed design, which they can do as an individual but not as a TC member)
18:16:37 <Myon> that seems like an unnecessary restriction
18:16:38 <spwhitton> before that, no restrictions.
18:17:01 <spwhitton> smcv: I guess they'd switch back and forth between those roles as appropriate?
18:17:07 <Myon> they should ask themselves if they should be involved more, but excluding any work in other areas seems restrictive
18:17:59 <marga> Yeah, I'm not sure how that separation can be done really
18:18:24 <marga> In their "TC facilitator" role, they shouldn't do design work, but any DD can do design work in their developer work
18:18:28 <Myon> given early invocation is supposed to (more) informal anyway
18:18:31 <marga> (role)
18:18:50 <spwhitton> marga: do you foresee problems?  I am inclined to assume it would be handleable.
18:19:07 <smcv> so just aim to be clear about whether any particular contribution is with or without TC hat on?
18:19:11 <marga> Yeah, I also think it should be handleable, I wouldn't want to over-prescribe
18:20:04 <spwhitton> smcv: yeah.
18:20:08 <spwhitton> maybe that should be written down too
18:20:14 * spwhitton adds to pad
18:20:26 <smcv> yeah, I'm fine with that as an answer but I think we should say it
18:20:39 <spwhitton> sigh I can't login
18:21:06 <spwhitton> #info also note that facilitator should be careful about whether or not they are contributing as the facilitator or not, esp. when it comes to design work
18:21:15 <spwhitton> okay, anyone up for writing this down?
18:21:41 <marga> I guess I can take it
18:22:08 <spwhitton> #action marga to commit final version of early invocation to tech-ctte.git procedures/
18:22:20 <spwhitton> bremner: I mistyped your action, it looks like
18:22:24 <spwhitton> sorry about that
18:22:26 <Myon> thanks
18:22:28 <spwhitton> thank you marga for taking on this one
18:22:31 <marga> Will we then publish them somewhere else as well?
18:23:07 <spwhitton> marga: I suggested we post to d-d-a pointing to our repo once we're done.  we could also add links to the repo to our wiki page.
18:23:30 <marga> Ok
18:23:53 <spwhitton> we can talk about that next time
18:24:10 <spwhitton> #info at the next meeting we should consider how we'll publicise the new procedures
18:24:14 <spwhitton> #topic Recruitment
18:24:21 <spwhitton> this wasn't on the agenda but I had intended it to be
18:24:31 <spwhitton> we are going to want two new people, right?
18:24:36 <marga> Yup
18:24:55 <spwhitton> I guess we should send out the usual request and also run fil's script?
18:25:01 <marga> And we're already in September which was usually when we started our recruitment efforts
18:25:02 <spwhitton> wasn't there one of us who had learned how the script works?
18:25:40 <marga> Uhm...  I think last time fil had sent it and also documented how it works.
18:26:02 <spwhitton> okay.  well, I can probably give it a shot and also send out the recruitment mail.
18:26:13 <ehashman> two new people TT_TT
18:26:37 <spwhitton> #action spwhitton to send out request for volunteers
18:26:46 <spwhitton> #action spwhitton to give fil's mail-sending script a shot
18:26:51 <spwhitton> any other ideas on this?
18:27:12 <spwhitton> for the past few years there have not been many volunteers.
18:28:04 <Myon> is there a list of people that have been asked before and declined (so it probably doesn't make sense asking again)?
18:28:15 <Myon> or do we just start from scratch?
18:28:38 <marga> Yeah, fil hat that data somewhere...
18:29:07 <spwhitton> Myon: oh that's a good point
18:29:29 <spwhitton> well, I guess for now we just have to ask and see what we get.
18:29:34 <Myon> or even some list of people that we would like to have on board
18:29:35 <spwhitton> people can change their minds.
18:30:17 <spwhitton> #topic Any Other Business
18:30:22 <spwhitton> #action spwhitton to look into jitsi for next time
18:30:27 <spwhitton> anything else to raise anyone?
18:30:39 <smcv> you're going to hate me for this
18:30:40 <smcv> but
18:30:48 <smcv> regarding the merged-/usr megathread
18:30:55 <marga> Not from me, I'm happy to try jitsi next time :)
18:30:58 <smcv> do we need to issue more specific advice?
18:31:23 <marga> You've already participated in the thread a few times, right?
18:31:25 <spwhitton> smcv: I've been following the thread with that in mind, but so far no role for the TC has become apparent to me
18:31:59 <smcv> we've said "we want bookworm to be merged-/usr" and some maintainers have already interpreted that as "enabling testing/unstable on a non-merged-/usr system is already unsupported"
18:32:07 <smcv> which was certainly not *my* intention
18:32:26 <spwhitton> ah right this "there's supported and there's supported" thing
18:32:37 <spwhitton> yes, it would probably be good for us to distinguish between those
18:33:10 <smcv> my intention was more like the timeline I mentioned in the thread: do the transition during the bookworm cycle, bookworm packages must support being installed on non-merged-/usr systems, packages in bookworm+1 are not required to
18:33:29 <spwhitton> smcv: I think we perhaps need a summary of that particular point of contention and request for clarification as a bug, and then we handle it?
18:33:38 <bremner> do we have the wording in the original bug handy?
18:33:53 <smcv> or even: bookworm packages must support (same) for a transitional period, we aim for that transitional period to end when bookworm+1 opens
18:34:01 <marga> Uhm, I thought bullseye was the transitional one and bookwork can drop support.
18:34:06 * gwolf is late for meetin, sorry! :-( Got tied up with RL
18:34:24 <smcv> marga: our understandings clearly differ on this
18:34:27 <spwhitton> marga: yeah, I don't think we are all automatically in agreement with smcv, i.e. we need to handle it as a bug.
18:34:49 <spwhitton> bremner: if wayland emacs would be nicer, I could paste you a msgid.  alas.
18:34:52 <smcv> I think we don't need to wait for a non-TC person to raise this, we can "offer advice"
18:35:23 <smcv> or one of us can open the bug with "this is not as clear as I thought it was, I think we should offer advice"
18:35:37 <marga> I don't have much of an opinion here. I just know that this was raised back in 2018 for bullseye and we ruled that bullseye should support both. And then last year we ruled that bookworm didn't need to support both anymore.
18:35:38 <spwhitton> smcv: that's what I was suggesting.  can y ou open the bug?
18:35:47 <bremner> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636
18:35:49 <bremner> fwiw
18:35:56 <smcv> yeah I'll do that
18:36:18 <spwhitton> #action smcv to open bug to use "offer advice" power to clarify status of merged-/usr support for bookworm qua testing
18:36:29 <spwhitton> thank you
18:36:34 <spwhitton> okay then I think we are done ..?
18:36:34 <gwolf> oh, I see I missed basically _all_ of the meeting (given we are in AOB already). Sorry :-(
18:36:38 <smcv> fwiw my interpretation of Ansgar's request was that the *request* was to have the bookworm cycle as the transitional period
18:37:00 <marga> smcv, why should bookworm stay transitional and only bookworm+1 be the one that drops support?
18:37:06 <bremner> hrm, my reading of the bug closing is the bookworm (the release) should only support merged-usr
18:37:17 <bremner> but bookworm is not released yet
18:37:21 <smcv> marga: because non-merged-/usr bullseye installations exist
18:37:32 <spwhitton> bremner: that is also a reasonable reading.
18:37:58 <bremner> that would make lack of support for merged user by packages RC; not sure if that is a real problem
18:38:18 <Myon> since bullseye didn't force the merge, all systems upgraded to bullseye won't be merged
18:38:32 <gwolf> I have the impression (but am not yet "submerged" into the topic as of right now) of agreeing with bremner's interpretation
18:38:46 <smcv> bremner: we have an ambiguity here, we are talking about "bookworm" to mean "the 2021-2023 period of development" but also to mean "bookworm release day in mid 2023"
18:38:47 <marga> smcv, can you explain a bit more, please? Why does non-merged-usr bullseye installations mean that bookworm needs to support it as well? Otherwise we will always need to support it.
18:39:00 <bremner> smcv: for me, the latter
18:39:17 <bremner> smcv: but, yeah, I see the ambiguity
18:39:20 <smcv> I'll try to be clear about which of those I'm talking about at any given time, but it's hard
18:39:26 <marga> Ah, yes, I also mean bookworm the release in 2023.
18:39:28 <gwolf> smcv: Well, I understand it as being "bookworm, the released set of things that will appear hopefully somewhere in 2023"
18:39:33 <smcv> right
18:39:49 <smcv> but
18:40:19 <smcv> if we are going to have an upgrade path in which users of bullseye can do (potentially partial) upgrades to bookworm
18:40:25 <spwhitton> it's about how much or little control we have over the order in which packages are upgraded the day after release day.
18:40:49 <smcv> then the important flag day is not really bookworm r0, but testing/unstable 1 day after bookworm r0
18:41:04 <smcv> *that* is the point at which packages can start assuming merged-/usr
18:41:14 <smcv> (assuming the timeline I outlined in the thread)
18:41:19 <bremner> smcv: what does r0 mean here?
18:41:23 <smcv> release day
18:41:37 <bremner> ok. so 1 day difference?
18:41:40 <gwolf> i.e. at some point having usrmerge as a required package
18:41:48 <gwolf> essential?
18:41:52 <smcv> well, it's more about which stream you are on than a point in time
18:41:56 <bremner> smcv: oh, I get it, you mean in testing vs in stable
18:42:15 <spwhitton> gwolf: bin:usrmerge is only for performing a transition.  the state of the system is not the same as whether that package is installed or not.
18:42:27 <spwhitton> for example a freshly debootstrapped bullseye never needs that package
18:42:42 <smcv> my understanding is that to make bullseye->bookworm upgrades possible, all packages in bookworm need to be able to cope with being installed onto a non-merged-/usr system
18:42:49 <gwolf> right, but it is a way to express it. Many systems do not need the package, but would it hurt to have it installed if it simplifies things?
18:43:04 <spwhitton> smcv: unless we do some crazy thing to guarantee bin:usrmerge is installed very early in the upgrade.
18:43:17 <smcv> fwiw I've been trying to be careful to talk about merged-/usr, not about usrmerge
18:43:52 <smcv> the state of the system, not the package that is one specific implementation of how to turn a non-merged-/usr system into a merged-/usr one
18:44:15 <spwhitton> do we think this has to be resolved in advance of our next meeting?  if not, I'd like to suggest we wait for smcv's bug filing before discussing more, because then we will have terminology readily available, a list of the issues, etc.
18:44:24 <gwolf> smcv: I understand, and me bringing up the package itself here might make the waters more muddy. But having tooling that assumes we have a merged-usr system is easier to express in terms of having the package installed
18:44:33 <gwolf> specially if it's a noop on already-merged systems
18:44:54 <smcv> IMO, the department of detailed design is welcome to iterate on usrmerge or any other implementation
18:45:04 <smcv> but with TC hat on, I'm not, and should not
18:45:11 <gwolf> right, /me shuts up about detailed design
18:46:32 <smcv> related issues that might be in scope for this, or might be a parallel bug (?)
18:47:03 <smcv> if a package, when built on a merged-/usr system, produces binaries that don't on non-merged-/usr, is that RC now?
18:48:05 <smcv> and I think there was another thing we might want to say explicitly, but I've forgotten it, sorry
18:48:25 <spwhitton> smcv: well, I'm happy to trust your judgement about the number of bugs to file.
18:48:32 <smcv> whether that class of bug is RC is really a release team question rather than a TC question
18:48:54 <smcv> but we can always offer advice "in our opinion it (should|should not) be treated as RC"
18:48:55 <bremner> smcv: this might be an exception to that general rule
18:49:08 <smcv> and I'm sure the release team will take that into account
18:49:21 <spwhitton> smcv: I don't think the responsibilities are as clear cut as that.
18:49:29 <bremner> I mean, if we decide that non-merged-/usr is not supported, I guess it would be bizarre to make that RC
18:49:45 <spwhitton> what the intro to Policy says about the relationship between policy and the release team probably applies to us too.
18:50:09 <smcv> during a transitional period I think it maybe does have to be RC, if we want arbitrary partial upgrades to work
18:50:31 <marga> But then when do we drop the support?
18:50:34 <smcv> because until those bugs are RC, it's not safe to make buildd chroots merged-/usr
18:50:37 <marga> There needs to be an end
18:51:05 <smcv> but if it's not safe to make buildd chroots merged-/usr, then we can't have an automatic migration mechanism that makes all systems merged-/usr
18:51:17 <bremner> smcv: you lost me. aren't we making less things RC by dropping support for non-merged-/usr?
18:51:52 <smcv> marga: my intention was: yes there is an end, and it is when we reopen unstable uploads after releasing bookworm
18:52:07 <marga> In any case, I think I'm in favor of postponing to next time, if smcv will file a bug with all the details.
18:52:23 <smcv> bremner: after bookworm yes, but today no
18:52:26 <smcv> I think
18:53:07 <smcv> or at least I don't see a transitional path that gets us there from here in the usual Debian way otherwise
18:53:18 <spwhitton> it seems fine for us to decide by the time of our next meeting, so I'll end the meeting here
18:53:21 <spwhitton> #endmeeting