18:58:57 <elbrus> #startmeeting
18:58:57 <MeetBot> Meeting started Wed Jun 28 18:58:57 2023 UTC.  The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:58:57 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:01 <elbrus> Sebastinas, ginggs, kibi, pochu, adsb, jcristau, ivodd, jmw ^
18:59:01 * kibi o/
18:59:12 <elbrus> #topic Admin
18:59:14 <jmw> o/
18:59:26 <elbrus> #info Previous minutes: http://meetbot.debian.net/debian-release/2023/debian-release.2023-05-24-18.58.html
18:59:36 <elbrus> #info elbrus had an action to start a thread about a sprint
18:59:42 <elbrus> did that, but no reply
19:00:13 * elbrus wonders if ginggs and Sebastinas are around too :)
19:00:27 <elbrus> #topic bookworm released (review)
19:00:36 <elbrus> we released \o/
19:00:44 <kibi> \o/ indeed \o/
19:01:03 <ginggs> o/
19:01:20 <jmw> elbrus: there are rumours of a cambridge mini-conf in november, I'm sure the venue could be persuaded to lend us a boardroom for a couple of days
19:01:21 <elbrus> and as after the release is before the release, maybe it's good to check what we liked and what might want improvements
19:01:30 <elbrus> jmw: cool
19:01:47 <jmw> I can tip off steve if we want to do that
19:03:01 <elbrus> jmw: any idea when the rumours will be communcated?
19:03:06 <elbrus> +i
19:03:23 <jmw> he's waiting for availability dates I think
19:03:31 <elbrus> ack
19:03:40 <jmw> as the venue is no longer his employer
19:03:47 <elbrus> I would be happy to try and make it to Cambridge
19:04:21 * ginggs too
19:04:34 <elbrus> so, let's see
19:04:38 <elbrus> back to topic?
19:05:23 * jmw failed at keeping up with topic
19:05:40 <elbrus> I felt we still had quite some unblock requests; what was your feeling?
19:06:20 <elbrus> overall, I think the freeze policy served us well
19:07:19 <elbrus> but I like to stress more in the future that they are not rules set in stone (I prefer to refer to them as strong guidelines)
19:07:56 <kibi> trying to avoid getting second-guessed and yelled at?
19:08:00 <ginggs> i think fewer key packages would have meant fewer unblock requests
19:08:05 <elbrus> not to get more unblock requests, but to put more enphesis on the ideas behind the guidelines
19:08:27 <elbrus> ginggs: ack, I want to propose that in the next topic; improvement proposals
19:09:00 <elbrus> on the other hand, most unblocks came late, around the time everything needed an unblock
19:09:10 <elbrus> at least, that's my feeling
19:09:15 <elbrus> (no stats)
19:09:36 <elbrus> (where are nthykier stats when you need them ;) )
19:10:14 <elbrus> and yes kibi, less guessing is good
19:11:17 <elbrus> what did people think of the length of the freeze?
19:12:15 <ginggs> too long :)
19:12:18 <elbrus> did I drive to hard to release earlier?
19:12:39 * kibi :(
19:13:06 <elbrus> because I believe freezing is needed for the release, but bad for motivation of most developers
19:13:18 <elbrus> so I think it should be as short as we can manage
19:13:50 <jmw> getting the balance right is almost impossible. it needs to be long enough to get stuff done and not so long that everybody burns out
19:14:01 <elbrus> ack
19:14:17 <kibi> short means burning out other people
19:14:23 <elbrus> the burning out is only a small group
19:14:36 <elbrus> I think most people are waiting it out
19:14:51 <elbrus> I think d-i needed the time in the end, right?
19:14:59 <kibi> YES
19:15:11 <kibi> I don't think you pushed too hard. It just wasn't possible anyway.
19:15:30 <kibi> But if the general impression here is we should go even *faster*, I'm not sure how that's going to work.
19:15:52 <jmw> remember the cycle was overall a bit shorter this time, because bullseye was released in august. so that probably means the freeze was busier as a result
19:16:05 <jmw> trixie will likely be a bit more balanced
19:16:42 <jmw> (unless we freeze it tonight)
19:17:00 <jmw> (please do not do that)
19:18:00 <elbrus> kibi: d-i development happens during the freeze, is that out of habit/motivation, or are there other reasons (like a more stable unstable)?
19:18:20 <elbrus> (not wanting to sound offensive)
19:19:27 <kibi> did anyone see anything happen after the non-free-firmware vote?
19:19:38 <kibi> nothing moved until I pushed for it
19:19:49 <elbrus> full ack
19:19:51 <kibi> d-i isn't quite the same, but there is almost nobody to work on it
19:20:13 <kibi> (not to diminish contributions from others, we just don't have enough hands)
19:20:40 <kibi> and yes, lots of things happen during a release cycle, and we cannot do/undo/redo all the time along the way
19:20:54 <kibi> so the *stabilization* period is where we *stabilize*
19:21:03 <kibi> there's no real *development* going on anyway
19:21:11 <kibi> there are shitloads of bugs, and we investigate/fix when we can
19:21:19 <elbrus> ack
19:21:27 <kibi> look at GRUB, look at shim.
19:21:49 <kibi> most issues we're getting are about failures to install GRUB (as far as I can see), which makes installation is busted.
19:22:01 <elbrus> too little amount of people caring to help the core ...
19:22:10 <kibi> so exact same story as always
19:22:21 <kibi> you can call it “d-i team has bad habits”
19:22:27 <elbrus> I don't
19:22:44 <kibi> but it really is “the release is happening soon, let's make sure it's not too broken”
19:22:49 <elbrus> I call it : d-i team deserves to be a bigger team"
19:23:13 <kibi> bullseye was miscommunication between us, I won't rehash that.
19:23:33 <kibi> bookworm was *incredibly hard* personally, even if I pushed back everything like health, work, etc. to concentrate on Debian
19:23:45 <pochu[m]> o/ sorry guys I'm only half here
19:24:02 <kibi> for what, 4(.5) months entirely?
19:24:26 <kibi> it's not clear trixie would require the same amount of work. but clearly faster faster faster isn't something I like to read.
19:25:13 <elbrus> understood, in this discussion it's clear where the pain is
19:26:29 <elbrus> and kibi, I think Debian isn't worth pushing back on health (even if I am guilty of doing that too maybe)
19:28:15 <kibi> also thanks for accommodating the reordering I suggested, but even that led to suboptimal results
19:28:42 <kibi> (like crowdsec that wants to be a fail2ban on steroids that doesn't actually bans ssh attackers because of a gross miconfiguration issue, so yay…)
19:30:06 <kibi> we have several k packages going into the desktop installs, lots of moving pieces; but more importantly, the kernel side is hard to stabilize, it takes time to get a feeling whether this or that version helped, didn't, usually a mix of both, and whether the next one is going to be better (if any)
19:30:42 <kibi> I'm not sure how we could expect everything to fall into place in the bat of an eye
19:31:06 <kibi> I'll shut up now and let others answer regarding non-di matters.
19:33:29 <elbrus> thanks kibi for your feedback above, it's much appreciated by me
19:35:24 <elbrus> another point I want to bring up in the review: we nacked KDE and plasma because of the big amount of packages
19:35:41 <elbrus> (well, plasma got accepted in the end)
19:36:05 <elbrus> while a monolitic source would fit better in our workflow
19:36:37 <elbrus> is that something we should aim to improve in our workflow?
19:37:53 <pochu[m]> improving migration/unblock of a big set of packages?
19:38:31 <elbrus> particularly creating a view on sets of packages instead of individual packages I guess
19:39:54 <elbrus> anyways, I have a proposal for that, so maybe to the next topic?
19:40:05 <elbrus> #topic ideas for trixie development and freeze policy
19:40:28 <elbrus> I was thinking about a list
19:40:56 <elbrus> for (key) packages that track a stable upstream branch
19:41:28 <elbrus> where we are agreeing with the maintainers, ideally well before the freeze
19:41:59 <elbrus> that the upstream stable branch policy alignes with our guidelines
19:42:10 <elbrus> targeted fixes, ect
19:42:17 <elbrus> s/ect/etc/
19:43:14 <elbrus> the security team already has several (about 20) package that they'll take upstreams for
19:44:10 <elbrus> packages on this list would be (semi-automatically) exempted from our no-upstream uploads guideline
19:46:04 <elbrus> the problem I want to address here is that I don't want to baby sit maintainers
19:47:22 <pochu[m]> If we have already asked new upstream releases for stable, we could follow that for the freeze
19:47:38 <pochu[m]> s/asked/acked/
19:47:39 <elbrus> I'm trying to balance the unblock work vs trusting maintainers...
19:47:53 <elbrus> pochu[m]: exactly
19:48:18 <pochu[m]> But for something like KDE/plasma, it was a tough call
19:48:32 <elbrus> not denying that
19:48:33 <pochu[m]> I think the point in the freeze matters there
19:49:06 <pochu[m]> I'm all in favor of accepting more point releases, but at some point it needs to stop even during the freeze
19:49:21 <elbrus> to be clear, you think I accepted plasma too late?
19:49:51 <elbrus> and you think it's better to have that during a point release?
19:50:25 <elbrus> I was more reasoning, if it's acceptable for a point release, it's OK for the freeze too, but I hear you say something different
19:50:47 <elbrus> or do you mean *upstream* point releases?
19:50:51 <kibi> I read “point releases” as “upstream stable releases”.
19:51:01 <elbrus> ack, me too after re-reading
19:51:02 <jmw> yes, there is a terminology clash here
19:51:35 <jmw> upstreams will carry on doing their own bugfix releases all the way through our freeze. the hard question is when do we stop taking them in order to get ourselves geared up for releasing
19:51:59 <elbrus> ok, so more upstream point release (for the right set of packages) but not too late in the freeze....
19:52:02 <elbrus> makes senses :)
19:53:14 <jmw> I admired simon's approach in #1036849
19:53:14 <elbrus> so the idea of the list is something I could try to work out?
19:53:24 <pochu[m]> elbrus: sorry I didn't mean that. I haven't really followed the freeze much unfortunately
19:53:37 <jmw> "this happened during freeze and we should ship it but it's not so crucial it has to go in right now"
19:54:01 <Sebastinas> Oh, meeting.
19:55:37 <elbrus> jmw: I admit that phrasing in request is extremely relevant
19:56:46 <elbrus> Sebastinas: your favorit topic is still on the roll if we continue after 20
19:56:59 <Sebastinas> :D
19:57:25 <elbrus> #action elbrus to work out the key package upstream acception list
19:57:45 <elbrus> other idea, mentioned by ginggs already today
19:57:51 <elbrus> less key packages
19:58:07 <elbrus> I want to do two things
19:58:19 <jmw> I guess the freeze policy could cite that bug as an example of being a good freeze citizen, that can't hurt
19:58:27 <elbrus> ack
19:58:32 <elbrus> drop <!nocheck> build-profile Build-Dependencies from key package calculation
19:59:04 <elbrus> I'm pretty sure we discussed this before and we had agreement at the time
19:59:14 <jmw> you'll have to unpack that a bit for me
19:59:15 <elbrus> but bringing it up nevertheless
19:59:20 <elbrus> ack
19:59:54 <elbrus> key packages are calculated from essential + something, their dependencies and build dependencies
19:59:58 <elbrus> and that recursively
20:00:11 <elbrus> we do that because we promise you can rebuild
20:00:34 <elbrus> but running tests isn't supposed to change the build binary
20:01:30 <elbrus> so we can promise you can build the binaries under the nocheck build profile even if the build dependencies for the tests are not available
20:02:06 <elbrus> and that can be fixed late in the release if we really want to build proper, by dropping the dependency and skipping the tests
20:02:32 <elbrus> I don't *want* to (auto) remove packages, but it has proven to work so well to get things fixed
20:02:44 <elbrus> to threaten with it
20:03:01 <elbrus> *and*
20:03:17 <textshell> sounds like a lot of late game RC bugs with type FTBFS... Which are just stressful and busywork?
20:03:30 <elbrus> a reduced key package set means less packages that need review during the hard freeze
20:03:56 <elbrus> textshell: it would be easily detectable
20:04:10 <elbrus> so we would have monitoring in place
20:05:08 <elbrus> and, why do you think it's late game?
20:05:19 <elbrus> I expect it to shift problems to early game
20:05:24 <elbrus> and make it easier to manage
20:05:57 <elbrus> because some RC bugs are now only fixed late because they are "protected"
20:06:27 <elbrus> jmw: did I unpack enough?
20:06:35 <textshell> From my tracking of RC bugs a lot of the where rebuilds and rerebuilds that found more FTBFS. But i was watching non key packages a lot more then key packages. Yes RC for key packages means not that much.
20:06:36 <jmw> yes, thanks
20:07:42 <textshell> key packages tend to carry RC bugs through multiple full debian releases without a "problem"...
20:07:43 <h01ger> double (default) migration times for keypackages with rc bugs? so there's still a weak stick? ;)
20:08:18 <elbrus> h01ger: a lot of key packages with RC bugs don't see uploads...
20:08:36 <elbrus> so the weak stick is very weak
20:08:55 * h01ger nods
20:09:43 <elbrus> second idea: drop tasksel from key package list and manage ourselves which "tasks" we consider key
20:10:31 <elbrus> last cycle we had an RC bug in a GUI to view the element system, which was "protected" because it was pulled in by a desktop
20:11:06 <elbrus> obviously, this might impact d-i
20:12:15 <elbrus> but I don't know yet exactly how that works, but I *suspect* we can fix tasksel to drop tasks if they were to miss the release and d-i would be fine?
20:12:28 <elbrus> or am I now rambling and need to do more homework?
20:12:38 <kibi> the question is whether you're willing to drop desktop environments at a moment's notice
20:13:10 <kibi> d-i is only indirectly in the equation here, as the one thing that presents options to users
20:13:17 <elbrus> like other non-key but important packages
20:13:24 <elbrus> we'll try to keep them on board
20:13:41 <elbrus> firefox-esr was about to be autoremoved this freeze
20:14:21 <elbrus> and I like us to think about what *we* as the Release Team require
20:14:25 <elbrus> Gnome?
20:14:32 <elbrus> Gnome and KDE?
20:14:39 <elbrus> Gnome or KDE?
20:14:51 <elbrus> ...
20:15:09 <elbrus> it should be our control, and not the tasksel maintainer
20:15:19 <elbrus> s//under/
20:15:30 <elbrus> ^ bad regexp
20:16:13 <elbrus> we don't need to decide now, but dropping tasksel from the key package set gives us that option
20:16:32 <elbrus> obviously we would need to think about which "tasks" then
20:16:34 <smcv> I think there is a distinction to be made between "the amount of gnome that our users get by default", and "the minimum viable product for what gnome users *could* get by default"
20:16:48 <elbrus> full ack on that too
20:16:57 <smcv> (and same for kde and the rest of course)
20:17:11 <kibi> if the release team wants to maintain tasksel, that's fine with me
20:18:09 <smcv> like, can we release a gnome desktop without gnome-shell? clearly no
20:18:11 <elbrus> if the release team would maintain it, I would split it in a lot of different source packages such that it can be easier handle by our tooling for key packages
20:18:45 <smcv> but can we release it without its preferred PDF reader, if we had to? clearly yes
20:18:50 <elbrus> I don't need every tasksel package to be key, just because we want some DE
20:19:28 * h01ger has no stakes in this, but i wouldnt find it unreasonable if the release team said "we only require GNOME to be functional" to release. given that warning is given early etc
20:19:47 <h01ger> there are RC bugs for a reason :)
20:20:29 <elbrus> indeed, I don't want to remove stuff from the release, I want to remove stuff from the key package set
20:20:43 <elbrus> of course that means it *could* drop out of the release
20:20:46 <smcv> if there are fewer key packages, does that mean maintainers of key-ish packages need to be more proactive about downgrading sort-of-RC-but-not-really bugs?
20:20:49 <elbrus> but that never happens overnight
20:21:29 <smcv> it's quite common for something relatively edge-case to be filed as RC because if it happens to you, the consequences are very bad, like total inability to log in or whatever
20:21:40 <elbrus> smcv: that would help, but asking for ${suite}-can-defer usertag can help too
20:21:46 <elbrus> wait
20:21:57 <elbrus> key-ish, yes
20:22:28 <h01ger> smcv: IMO maintainer should downgrade unreproducible/fringe cases/bugs more often.
20:22:57 <elbrus> smcv: particularly current key packages should triage more
20:23:08 <elbrus> not more
20:23:18 <elbrus> but more proactive
20:23:47 <elbrus> not should, but it would help if they would
20:24:07 <elbrus> and that will be true for key-ish packages even more so, yes
20:24:09 <smcv> with gnome team hat on, I do what I can, but there's a limit to how much time/energy I can spend on unclear bug reports (or users being entitled)
20:24:32 <elbrus> smcv: I think that if a package is threatened with removal
20:24:36 <elbrus> you get more eyes
20:25:01 <elbrus> that's one of the lessons I learned this cycle
20:25:19 <elbrus> recall I once threatened to remove nearly everything from testing?
20:25:21 <smcv> as long as those eyes aren't the subset of our developers who consider it to be unacceptable to downgrade or close bugs
20:25:37 <elbrus> about 10 RC bugs in key packages were fixed that week
20:26:01 <smcv> *unsolved bugs, obviously
20:26:13 <smcv> I hope everyone agrees with closing fixed bugs :-)
20:26:58 <elbrus> I have faith
20:28:08 <elbrus> ^ topic is nearly up
20:28:33 <elbrus> anything else people want to say or suggest for the trixie cycle?
20:28:47 <jmw> I don't have strong feelings either way about this but it sounds like it could use some refining and/or consultation
20:28:56 <elbrus> (can also be done in a future meeting of course or otherwise)
20:29:23 <elbrus> jmw: I agree, but I wanted to get a bit of feeling of what people thought
20:29:27 <jmw> ack
20:29:39 * elbrus presented some of these ideas in Hamburg too
20:29:57 <elbrus> #action elbrus: flesh out key package proposals
20:30:10 <elbrus> #topic Transitions
20:30:28 <elbrus> Sebastinas: your turn :)
20:30:59 <Sebastinas> There's the post-release rush of small transitions.
20:31:11 <Sebastinas> They all seem to be progressing without much issues.
20:31:37 <Sebastinas> I plan to ACK glibc 2.37 soon.
20:31:46 <elbrus> openmm has some issues?
20:32:04 <Sebastinas> That's one of the ones with an issue.
20:32:15 <elbrus> ack
20:32:40 <Sebastinas> But the rev dep already got an RC bug.
20:32:46 <elbrus> https://qa.debian.org/excuses.php?experimental=1&package=glibc isn't worrying, right?
20:34:32 <Sebastinas> So far I've seen some unrelated failures and the normal cases of uninstallable packages that are part of the transition.
20:35:11 <Sebastinas> After glibc, it's time to take a look at time64_t. Last time I checked there were still some discussions going on -devel.
20:35:26 <elbrus> bug #1036884
20:35:50 <elbrus> ginggs is doing some of that Ubuntu investigation I understood
20:36:21 <elbrus> do we need to engage more in that discussion?
20:36:46 <elbrus> I've read it all, but not engaged yed
20:36:58 <Sebastinas> Most of the thread is marked as unread.
20:37:01 <Sebastinas> I can't tell right now.
20:37:42 <elbrus> I think a big part is about what to do with our i386 arch
20:38:12 <kibi> it's almost as if the arch qual topic cannot be escaped
20:38:13 <helmut> I asked for people who'd want i386 to become time64 (in a consensus call) and got 2 (two) replies.
20:39:09 <helmut> If you think that result isn't clear (i.e. keep i386 time abi as vorlon initially suggested), we should GR it soon.
20:39:09 <elbrus> I think I missed our i386 ported in that discussion
20:39:33 <elbrus> porter*
20:40:11 <jmw> I have to dash, sorry
20:40:12 <jmw> nn
20:40:29 <elbrus> bye
20:41:06 <elbrus> Sebastinas: do you think you have time anytime soon to go through it to form your opinion?
20:41:39 <Sebastinas> Should be doable until the next meeting.
20:41:44 <elbrus> :)
20:41:46 <helmut> indeed, bunk did not reply to that discussion. In any case, I found smcv's reasoning very convincing.
20:42:30 <elbrus> I think smcv is in the other camp than bunk (the only registered porter for i386)
20:42:44 <smcv> I hesitate to say it because I don't have the energy to gain more hats, but I can't help wondering whether we'd have more i386 porters if we limited its scope to be "compatibility with ye olde binaries"
20:43:30 <elbrus> smcv: I think I share your idea but I think we (as a project) suck at deciding on matters like this
20:43:33 <smcv> I already have to fix e.g. multiarch coinstallability in $dayjob
20:43:37 <elbrus> we talked about it in Hamburg
20:44:02 <smcv> but I'm not willing to go and argue with upstreams about how important it is that they help us to support 20 year old CPUs
20:44:45 <elbrus> I had my share this release cycle too
20:44:52 <helmut> elbrus: how about asking bunk and putting it to GR if he objects?
20:44:54 <elbrus> (user of such an old CPU)
20:45:38 <elbrus> I would like us to use GR more for things like this, but I'm not a GR driver
20:46:20 <ginggs> shouldn't the onus be on someone who objects to drive a GR?
20:46:53 <smcv> someone did suggest on -devel what I understood to be: keeping i386 with a somewhat modern baseline, and having a separate port (with a different elf interpreter, and presumably multiarch tuple too) for the Geode use-case
20:46:54 <helmut> the bar was really low. all you had to do was object. and two did.
20:47:50 <elbrus> bookworm doesn't support Geode
20:48:27 <smcv> whatever hypothetical CPU is our official baseline now, then
20:48:34 <smcv> the one with no MMX and no SSE
20:48:54 <elbrus> https://www.debian.org/releases/bookworm/i386/release-notes/ch-information.en.html#i386-is-i686
20:49:11 <helmut> from my pov, the bottom line is that we should consider i386 to remain time32 for now and assume that the transition moves forward as planned. canonical has relatively tight timing on this as they need to fit it into 6 months
20:49:27 <smcv> although the suggestion of a separate port did include rolling back its baseline to i586 or thereabouts
20:49:46 <smcv> I don't know how they expect to run Rust code on that, the answer might be "not"
20:50:46 <elbrus> helmut I think I also agree with that, but not yet with my Release Team hat on
20:51:22 <elbrus> as in, I doubt too much about architectures
20:51:31 <aurel32> yeah, people have complained that the ISA got raised on many architectures (for instance s390x, mips, i386), but they never do the job of porting things like rust, nodejs or other language
20:53:46 * elbrus nearly needs to go to bed and fails to draw a good conclusion for this meeting
20:56:05 <elbrus> ok, we'll leave this topic here then
20:56:14 <elbrus> #topic AOB
20:56:23 <elbrus> anyone?
20:56:49 <ginggs> nothing here
20:58:01 <elbrus> #topic Next meeting
20:58:09 <elbrus> #info Next meeting is 26 July at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics)
20:58:17 <elbrus> #endmeeting