19:04:53 #startmeeting 19:04:53 Meeting started Wed Apr 24 19:04:53 2019 UTC. The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:04:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:05:06 Lets get started :) 19:05:21 #topic Admin 19:06:17 o/ 19:06:22 #info Minutes from last meeting are at http://meetbot.debian.net/debian-release/2019/debian-release.2019-03-27-19.01.html 19:06:57 #info nthykier had one item about sending a mail to team@ to discuss whether the meeting time is still ok; not done 19:08:10 #info jmw had a (non-listed) item about sending a d-d-a mail when we got below 300 RC bugs. This has happened (and we are now at ~133 RC bugs \o/) 19:08:15 #undo 19:08:15 Removing item from minutes: 19:08:24 #info jmw had a (unlisted) action item about sending a d-d-a mail when we got below 300 RC bugs. This has happened (and we are now at ~133 RC bugs \o/) 19:08:40 I think that was it for admin :) 19:09:34 Next up would be Transitions, but I don't think we have any of these at the moment 19:10:35 * elbrus is not the right person to know authoritive, but he doesn't think either 19:10:44 #topic Unblock queue 19:10:52 I think this topic is still relevant 19:11:51 (should we maybe ping people, in case they are not aware of the meeting, but are on-line?) 19:12:09 elbrus: by all means, please do 19:12:23 * elbrus fears to be not complete 19:12:40 kibi: pochu_: jcristau: jmw 19:12:46 We got 27 unblock requests pending us (related thanks to ivodd for pruning a lot of them the other day) plus about 10 waiting for requesters 19:12:47 ivodd: 19:12:48 that should do :) 19:12:59 we got there between us 19:13:40 :D 19:14:16 The oldest open unblock request we have is from March 16 AFAICT and is unanswered by us #924742 (just to get a feeling of the backlog) 19:14:55 looks like we are due for a clean up round on unblocks 19:15:45 * elbrus has the feeling there are several non-trivial ones in the older set 19:15:47 #info We got 27 unblock requsts waiting for us and 10 waiting for requester. Oldest one (waiting for RT) is about ~5 weeks old atm. 19:16:07 indeed, we are probably looking at rejecting or returning most of them with feedback 19:16:52 I have a general question 19:17:07 yes, please go ahaed :) 19:17:10 we do get pre upload requests once in a while 19:17:14 ... ahead* 19:17:55 nearly always what we tend to "want" is a package in unstable to diff with 19:18:34 so, should we encourage people to upload earlier, or is that shouting in our own foot? 19:19:05 You mean to be able to use d ? Or to get the unblock done in a single round trip? 19:19:29 (For the former, uploads to experimental is an option) 19:19:32 I mean, I was looking at blis this morning and thought that it may have been easier to just judge what the uploader wanted to migrate 19:20:02 * elbrus likes experimental, yes, but in this case that was even blocked already 19:20:13 ah, #926976 - we definitely want a debdiff in some form 19:20:45 I was thinking about roundtrips mostly 19:21:18 but I recognize it that we also want to encourage people to not upload to unstable too much 19:21:26 right - it is a double-edged sword; in many cases it is indeed faster as *most* uploads are beneign. 19:21:31 but if the fix is targetting testing... 19:21:59 Problem being we do not always agree on how a fix targeting testing should look 19:22:19 maybe we should say; uploads that can easily be reverted (e.g. not a new upstream version) are OK to try without a pre-approval 19:23:25 Would work for me. The tricky part is getting people to revert it again if it becomes an issue (mostly because sid can contaminate testing in some cases) 19:23:30 s/should/could/ 19:23:45 ack 19:24:02 I'll put this on my list for the freeze policy for buster 19:24:18 Thanks :) 19:24:24 s/buster/bullseye/ 19:24:35 not changing the policy so late 19:24:42 :D 19:25:35 Ok, unwinding back to the unblock queue - perhaps we should look at a work session to clean up the queue 19:25:45 (on IRC) 19:26:54 I typically only have about two hours in the evening (UTC+2) 19:27:00 but otherwise, fine with me 19:28:03 ok - I was thinking a weekend day actually :) All the same, I think I will action it for me to propose a timeslot :) 19:28:21 #action nthykier to propose some timeslots for cleaning up the unblock queue 19:29:15 if there is nothing else about unblock requests, I think I will move on to "Freeze progress" 19:29:25 #topic Freeze progress 19:30:11 nthykier: I appreciated your e-mail 19:30:22 describing our PoV 19:30:37 and looking forward to a date 19:30:44 Thanks - I was hoping it would give an overview of what I see us waiting for 19:31:50 from what is on my radar, it did 19:32:12 (not claiming a very good radar though) 19:32:49 At the moment, I think the most concerning one is #927825 as it might be a pandora's box of delay (best case is obviously a nice simple quick fix, but ...) 19:33:01 indeed 19:33:39 #info One of the primary release blockers is #927825 (as it keeps DSA from upgrading ARM buildd machines) 19:33:58 technically we can upgrade them, just we need to run them with the stretch kernel 19:34:25 I am not turning ARM into the new sparc 19:34:27 maybe i should upgrade an armel machine while keeping the old kernel so that we can at least test the armel userland 19:35:16 agreed this should get fixed, but it doesn't worry me that much it's not a kernel stability issue 19:35:27 it just looks like a driver issue 19:35:28 aurel32: hmm, indeed that would be useful from the PoV of ensuring that buster works on arm (userland vice) 19:36:28 if you (DSA) is ok with that in the interrim, then I think it would be a fine step towards weeding out possible unknowns for buster 19:37:12 aurel32: were we only missing the arm machines now? 19:37:17 well i don't think we should release buster with that issue, but at least we can progress forward 19:37:24 nthykier: yes 19:37:40 i mean it means we have one month to find the driver issue, looks doable for me 19:39:18 Sledge: have you been able to look at the issue? If not, I'll start a rough "bisect" with the kernel from backports 19:39:31 s/backports/snapshot/ 19:39:38 Thanks :) 19:40:54 #info #927825 is likely caused by a driver issue and fixing it within a month "looks doable" at the moment 19:41:39 [eating, not that anyone would probably have noticed] 19:42:02 elbrus: I forgot to include release-notes in my status update - do you have anything on that front? Are we missing anything there? 19:42:04 adsb: yeah you don't make that much noise :P 19:42:22 release-notes are coming along 19:42:36 as a first timer on that front, it looks ok 19:42:55 backlog isn't too bad, and mostly with promises 19:43:31 :) 19:43:34 and if they don't turn up, I think I'll manage to create some text 19:44:05 * elbrus is very glad that there is a response from the security team about the notes 19:44:37 all-in-all, I think the release notes are fine 19:44:40 Our main selling points (from chapter 2) appears to be Apparmor, better German manpages, nftables, better disk crypto (LUKS2) and then (hopefully) Secure boot support... :) 19:45:29 * pochu is preparing dinner as well, I'll be here intermitently 19:45:44 pochu: no worries, I think we are about to end (~15 minutes left) 19:45:50 (at most...) 19:46:19 I do not think I have any more to freeze progress 19:46:24 can't really commit to doing more doc work at the moment 19:46:43 (as opposed to fixing code issues) 19:47:18 kibi: please go fix code ;) 19:47:26 speaking of doc work - do we have any idea where the installation guide is (release-readiness-wise)? 19:47:47 I don't 19:48:14 and you didn't ask Holger? 19:48:21 #info Possible blind spot being the installation guide 19:48:21 or didn't get a response? 19:48:33 want me to ask/chase him? 19:49:16 yes please :) 19:49:31 * elbrus was asking kibi... :) 19:49:49 as the wiki says he would do it... 19:51:01 pochu: :P 19:53:44 elbrus: please do 19:54:03 #action elbrus will follow up on the progress of the installation guide 19:54:05 Thanks :) 19:54:10 ack 19:54:13 apparently I managed to uncover enough other issues to keep me busy, sorry about that 19:54:23 I think we are out of time, so I will move to AOB 19:54:33 #topic AOB 19:54:37 Any AOB? 19:54:51 two notes I like to make 19:55:22 1: I am glad I could use autopkgtest on spu to spot a regression before the point release 19:55:37 awesome :) 19:55:48 so I'll think about how to make that more automated 19:56:08 SGTM :) 19:56:19 2: I'm playing with arm64 on packet.net 19:56:44 depending on how that goes, that should be our next arch for autopkgtestng 19:56:50 autopkgtesting* 19:57:01 Sounds good as well :) 19:57:24 that's it from my side 19:57:26 * nthykier would be very excited to have more architectures in autopkgtests 19:57:30 Thanks for sharing :) 19:57:48 needs a couple of improvements to britney1 and 2 19:57:49 #topic Next meeting 19:57:53 #undo 19:57:53 Removing item from minutes: 19:58:15 (sorry, thought you were done) 19:58:38 I can elaborate, but I can also quiet :) 19:58:41 quite 19:58:47 quit 19:58:52 Ack, I will look forward to the patches :D 19:59:08 I'll need to discuss the design 19:59:15 I will move on as we are out of time :) 19:59:23 ack 19:59:32 (happy to discuss it later though) 19:59:37 #topic Next meeting 19:59:37 :) 19:59:52 Next meeting is (assuming no changes) ... 20:00:12 #info Next meeting is 22nd May at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics) 20:00:15 #endmeeting