18:58:57 #startmeeting 18:58:57 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:01 Sebastinas, ginggs, kibi, pochu, adsb, jcristau, ivodd, jmw ^ 18:59:01 * kibi o/ 18:59:12 #topic Admin 18:59:14 o/ 18:59:26 #info Previous minutes: http://meetbot.debian.net/debian-release/2023/debian-release.2023-05-24-18.58.html 18:59:36 #info elbrus had an action to start a thread about a sprint 18:59:42 did that, but no reply 19:00:13 * elbrus wonders if ginggs and Sebastinas are around too :) 19:00:27 #topic bookworm released (review) 19:00:36 we released \o/ 19:00:44 \o/ indeed \o/ 19:01:03 o/ 19:01:20 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 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 jmw: cool 19:01:47 I can tip off steve if we want to do that 19:03:01 jmw: any idea when the rumours will be communcated? 19:03:06 +i 19:03:23 he's waiting for availability dates I think 19:03:31 ack 19:03:40 as the venue is no longer his employer 19:03:47 I would be happy to try and make it to Cambridge 19:04:21 * ginggs too 19:04:34 so, let's see 19:04:38 back to topic? 19:05:23 * jmw failed at keeping up with topic 19:05:40 I felt we still had quite some unblock requests; what was your feeling? 19:06:20 overall, I think the freeze policy served us well 19:07:19 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 trying to avoid getting second-guessed and yelled at? 19:08:00 i think fewer key packages would have meant fewer unblock requests 19:08:05 not to get more unblock requests, but to put more enphesis on the ideas behind the guidelines 19:08:27 ginggs: ack, I want to propose that in the next topic; improvement proposals 19:09:00 on the other hand, most unblocks came late, around the time everything needed an unblock 19:09:10 at least, that's my feeling 19:09:15 (no stats) 19:09:36 (where are nthykier stats when you need them ;) ) 19:10:14 and yes kibi, less guessing is good 19:11:17 what did people think of the length of the freeze? 19:12:15 too long :) 19:12:18 did I drive to hard to release earlier? 19:12:39 * kibi :( 19:13:06 because I believe freezing is needed for the release, but bad for motivation of most developers 19:13:18 so I think it should be as short as we can manage 19:13:50 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 ack 19:14:17 short means burning out other people 19:14:23 the burning out is only a small group 19:14:36 I think most people are waiting it out 19:14:51 I think d-i needed the time in the end, right? 19:14:59 YES 19:15:11 I don't think you pushed too hard. It just wasn't possible anyway. 19:15:30 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 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 trixie will likely be a bit more balanced 19:16:42 (unless we freeze it tonight) 19:17:00 (please do not do that) 19:18:00 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 (not wanting to sound offensive) 19:19:27 did anyone see anything happen after the non-free-firmware vote? 19:19:38 nothing moved until I pushed for it 19:19:49 full ack 19:19:51 d-i isn't quite the same, but there is almost nobody to work on it 19:20:13 (not to diminish contributions from others, we just don't have enough hands) 19:20:40 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 so the *stabilization* period is where we *stabilize* 19:21:03 there's no real *development* going on anyway 19:21:11 there are shitloads of bugs, and we investigate/fix when we can 19:21:19 ack 19:21:27 look at GRUB, look at shim. 19:21:49 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 too little amount of people caring to help the core ... 19:22:10 so exact same story as always 19:22:21 you can call it “d-i team has bad habits” 19:22:27 I don't 19:22:44 but it really is “the release is happening soon, let's make sure it's not too broken” 19:22:49 I call it : d-i team deserves to be a bigger team" 19:23:13 bullseye was miscommunication between us, I won't rehash that. 19:23:33 bookworm was *incredibly hard* personally, even if I pushed back everything like health, work, etc. to concentrate on Debian 19:23:45 o/ sorry guys I'm only half here 19:24:02 for what, 4(.5) months entirely? 19:24:26 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 understood, in this discussion it's clear where the pain is 19:26:29 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 also thanks for accommodating the reordering I suggested, but even that led to suboptimal results 19:28:42 (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 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 I'm not sure how we could expect everything to fall into place in the bat of an eye 19:31:06 I'll shut up now and let others answer regarding non-di matters. 19:33:29 thanks kibi for your feedback above, it's much appreciated by me 19:35:24 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 (well, plasma got accepted in the end) 19:36:05 while a monolitic source would fit better in our workflow 19:36:37 is that something we should aim to improve in our workflow? 19:37:53 improving migration/unblock of a big set of packages? 19:38:31 particularly creating a view on sets of packages instead of individual packages I guess 19:39:54 anyways, I have a proposal for that, so maybe to the next topic? 19:40:05 #topic ideas for trixie development and freeze policy 19:40:28 I was thinking about a list 19:40:56 for (key) packages that track a stable upstream branch 19:41:28 where we are agreeing with the maintainers, ideally well before the freeze 19:41:59 that the upstream stable branch policy alignes with our guidelines 19:42:10 targeted fixes, ect 19:42:17 s/ect/etc/ 19:43:14 the security team already has several (about 20) package that they'll take upstreams for 19:44:10 packages on this list would be (semi-automatically) exempted from our no-upstream uploads guideline 19:46:04 the problem I want to address here is that I don't want to baby sit maintainers 19:47:22 If we have already asked new upstream releases for stable, we could follow that for the freeze 19:47:38 s/asked/acked/ 19:47:39 I'm trying to balance the unblock work vs trusting maintainers... 19:47:53 pochu[m]: exactly 19:48:18 But for something like KDE/plasma, it was a tough call 19:48:32 not denying that 19:48:33 I think the point in the freeze matters there 19:49:06 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 to be clear, you think I accepted plasma too late? 19:49:51 and you think it's better to have that during a point release? 19:50:25 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 or do you mean *upstream* point releases? 19:50:51 I read “point releases” as “upstream stable releases”. 19:51:01 ack, me too after re-reading 19:51:02 yes, there is a terminology clash here 19:51:35 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 ok, so more upstream point release (for the right set of packages) but not too late in the freeze.... 19:52:02 makes senses :) 19:53:14 I admired simon's approach in #1036849 19:53:14 so the idea of the list is something I could try to work out? 19:53:24 elbrus: sorry I didn't mean that. I haven't really followed the freeze much unfortunately 19:53:37 "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 Oh, meeting. 19:55:37 jmw: I admit that phrasing in request is extremely relevant 19:56:46 Sebastinas: your favorit topic is still on the roll if we continue after 20 19:56:59 :D 19:57:25 #action elbrus to work out the key package upstream acception list 19:57:45 other idea, mentioned by ginggs already today 19:57:51 less key packages 19:58:07 I want to do two things 19:58:19 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 ack 19:58:32 drop build-profile Build-Dependencies from key package calculation 19:59:04 I'm pretty sure we discussed this before and we had agreement at the time 19:59:14 you'll have to unpack that a bit for me 19:59:15 but bringing it up nevertheless 19:59:20 ack 19:59:54 key packages are calculated from essential + something, their dependencies and build dependencies 19:59:58 and that recursively 20:00:11 we do that because we promise you can rebuild 20:00:34 but running tests isn't supposed to change the build binary 20:01:30 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 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 I don't *want* to (auto) remove packages, but it has proven to work so well to get things fixed 20:02:44 to threaten with it 20:03:01 *and* 20:03:17 sounds like a lot of late game RC bugs with type FTBFS... Which are just stressful and busywork? 20:03:30 a reduced key package set means less packages that need review during the hard freeze 20:03:56 textshell: it would be easily detectable 20:04:10 so we would have monitoring in place 20:05:08 and, why do you think it's late game? 20:05:19 I expect it to shift problems to early game 20:05:24 and make it easier to manage 20:05:57 because some RC bugs are now only fixed late because they are "protected" 20:06:27 jmw: did I unpack enough? 20:06:35 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 yes, thanks 20:07:42 key packages tend to carry RC bugs through multiple full debian releases without a "problem"... 20:07:43 double (default) migration times for keypackages with rc bugs? so there's still a weak stick? ;) 20:08:18 h01ger: a lot of key packages with RC bugs don't see uploads... 20:08:36 so the weak stick is very weak 20:08:55 * h01ger nods 20:09:43 second idea: drop tasksel from key package list and manage ourselves which "tasks" we consider key 20:10:31 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 obviously, this might impact d-i 20:12:15 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 or am I now rambling and need to do more homework? 20:12:38 the question is whether you're willing to drop desktop environments at a moment's notice 20:13:10 d-i is only indirectly in the equation here, as the one thing that presents options to users 20:13:17 like other non-key but important packages 20:13:24 we'll try to keep them on board 20:13:41 firefox-esr was about to be autoremoved this freeze 20:14:21 and I like us to think about what *we* as the Release Team require 20:14:25 Gnome? 20:14:32 Gnome and KDE? 20:14:39 Gnome or KDE? 20:14:51 ... 20:15:09 it should be our control, and not the tasksel maintainer 20:15:19 s//under/ 20:15:30 ^ bad regexp 20:16:13 we don't need to decide now, but dropping tasksel from the key package set gives us that option 20:16:32 obviously we would need to think about which "tasks" then 20:16:34 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 full ack on that too 20:16:57 (and same for kde and the rest of course) 20:17:11 if the release team wants to maintain tasksel, that's fine with me 20:18:09 like, can we release a gnome desktop without gnome-shell? clearly no 20:18:11 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 but can we release it without its preferred PDF reader, if we had to? clearly yes 20:18:50 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 there are RC bugs for a reason :) 20:20:29 indeed, I don't want to remove stuff from the release, I want to remove stuff from the key package set 20:20:43 of course that means it *could* drop out of the release 20:20:46 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 but that never happens overnight 20:21:29 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 smcv: that would help, but asking for ${suite}-can-defer usertag can help too 20:21:46 wait 20:21:57 key-ish, yes 20:22:28 smcv: IMO maintainer should downgrade unreproducible/fringe cases/bugs more often. 20:22:57 smcv: particularly current key packages should triage more 20:23:08 not more 20:23:18 but more proactive 20:23:47 not should, but it would help if they would 20:24:07 and that will be true for key-ish packages even more so, yes 20:24:09 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 smcv: I think that if a package is threatened with removal 20:24:36 you get more eyes 20:25:01 that's one of the lessons I learned this cycle 20:25:19 recall I once threatened to remove nearly everything from testing? 20:25:21 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 about 10 RC bugs in key packages were fixed that week 20:26:01 *unsolved bugs, obviously 20:26:13 I hope everyone agrees with closing fixed bugs :-) 20:26:58 I have faith 20:28:08 ^ topic is nearly up 20:28:33 anything else people want to say or suggest for the trixie cycle? 20:28:47 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 (can also be done in a future meeting of course or otherwise) 20:29:23 jmw: I agree, but I wanted to get a bit of feeling of what people thought 20:29:27 ack 20:29:39 * elbrus presented some of these ideas in Hamburg too 20:29:57 #action elbrus: flesh out key package proposals 20:30:10 #topic Transitions 20:30:28 Sebastinas: your turn :) 20:30:59 There's the post-release rush of small transitions. 20:31:11 They all seem to be progressing without much issues. 20:31:37 I plan to ACK glibc 2.37 soon. 20:31:46 openmm has some issues? 20:32:04 That's one of the ones with an issue. 20:32:15 ack 20:32:40 But the rev dep already got an RC bug. 20:32:46 https://qa.debian.org/excuses.php?experimental=1&package=glibc isn't worrying, right? 20:34:32 So far I've seen some unrelated failures and the normal cases of uninstallable packages that are part of the transition. 20:35:11 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 bug #1036884 20:35:50 ginggs is doing some of that Ubuntu investigation I understood 20:36:21 do we need to engage more in that discussion? 20:36:46 I've read it all, but not engaged yed 20:36:58 Most of the thread is marked as unread. 20:37:01 I can't tell right now. 20:37:42 I think a big part is about what to do with our i386 arch 20:38:12 it's almost as if the arch qual topic cannot be escaped 20:38:13 I asked for people who'd want i386 to become time64 (in a consensus call) and got 2 (two) replies. 20:39:09 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 I think I missed our i386 ported in that discussion 20:39:33 porter* 20:40:11 I have to dash, sorry 20:40:12 nn 20:40:29 bye 20:41:06 Sebastinas: do you think you have time anytime soon to go through it to form your opinion? 20:41:39 Should be doable until the next meeting. 20:41:44 :) 20:41:46 indeed, bunk did not reply to that discussion. In any case, I found smcv's reasoning very convincing. 20:42:30 I think smcv is in the other camp than bunk (the only registered porter for i386) 20:42:44 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 smcv: I think I share your idea but I think we (as a project) suck at deciding on matters like this 20:43:33 I already have to fix e.g. multiarch coinstallability in $dayjob 20:43:37 we talked about it in Hamburg 20:44:02 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 I had my share this release cycle too 20:44:52 elbrus: how about asking bunk and putting it to GR if he objects? 20:44:54 (user of such an old CPU) 20:45:38 I would like us to use GR more for things like this, but I'm not a GR driver 20:46:20 shouldn't the onus be on someone who objects to drive a GR? 20:46:53 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 the bar was really low. all you had to do was object. and two did. 20:47:50 bookworm doesn't support Geode 20:48:27 whatever hypothetical CPU is our official baseline now, then 20:48:34 the one with no MMX and no SSE 20:48:54 https://www.debian.org/releases/bookworm/i386/release-notes/ch-information.en.html#i386-is-i686 20:49:11 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 although the suggestion of a separate port did include rolling back its baseline to i586 or thereabouts 20:49:46 I don't know how they expect to run Rust code on that, the answer might be "not" 20:50:46 helmut I think I also agree with that, but not yet with my Release Team hat on 20:51:22 as in, I doubt too much about architectures 20:51:31 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 ok, we'll leave this topic here then 20:56:14 #topic AOB 20:56:23 anyone? 20:56:49 nothing here 20:58:01 #topic Next meeting 20:58:09 #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 #endmeeting