18:59:01 <elbrus> #startmeeting
18:59:01 <MeetBot> Meeting started Wed Jun 24 18:59:01 2020 UTC.  The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:05 <elbrus> pochu, adsb, jcristau, kibi, ivodd, jmw, ginggs, Sebastinas, noahm ^
18:59:12 <Sebastinas> o/
18:59:15 <ginggs> o/
18:59:20 <pochu> o/
18:59:37 <elbrus> #topic Admin
18:59:52 <elbrus> #info Previous minutes: http://meetbot.debian.net/debian-release/2020/debian-release.2020-04-22-19.00.html
19:00:12 <elbrus> #info ginggs had an action for a patch to britney
19:00:35 <elbrus> (don't think that happened yet)
19:00:40 <ginggs> no progress
19:00:46 <elbrus> no worries
19:00:57 <elbrus> #info elbrus had an action for release architecture qualification; e-mail sent
19:01:11 <elbrus> and on the agenda for later
19:01:26 <elbrus> #info elbrus had an action to remove the copy disclaimer of the rc_policy; done
19:01:43 <elbrus> #info noahm had an action to review rc_policy
19:01:49 <elbrus> ;)
19:02:38 <elbrus> nothing yet I guess?
19:02:40 <noahm> I read it, anyway.
19:02:49 <noahm> no feedback atm
19:02:54 <elbrus> so, done
19:03:05 <elbrus> #topic Transitions
19:03:30 <elbrus> how's stuff going (I haven't followed much)
19:03:33 <elbrus> ?
19:03:33 <pochu> Sebastinas: you're up :)
19:03:40 <Sebastinas> boost is about to finish.
19:03:44 <Sebastinas> kig should migrate tonight
19:04:09 <Sebastinas> icu is blocked on chromium
19:04:31 <adsb> o/
19:04:37 <adsb> (was eating)
19:04:45 <Sebastinas> there was an upload recently but that is broken with current ffmpeg
19:04:55 <pochu> what's kig?
19:05:09 <Sebastinas> Last reverse depenency of boost1.67
19:05:22 <pochu> ah cool
19:05:45 <elbrus> the one with the upstream not ready yet?
19:05:50 <pochu> there's haskell ongoing too, but those need sourceful uploads due to the doc abi bump
19:06:01 <Sebastinas> elbrus: Yes, python support was temporarily disabled.
19:06:09 <elbrus> o, good
19:06:30 <Sebastinas> There are some smaller ones without issues.
19:06:33 <elbrus> is the haskell team picking it up?
19:06:48 <elbrus> I pinged some people on #d-devel a while back
19:07:04 <Sebastinas> Except for flint (which wasn't coordinated)
19:07:22 <elbrus> seems much better than several weeks ago (haskell)
19:07:55 <pochu> elbrus: yeah I think they are. it looks in a better shape than since I poked them last week
19:08:28 <elbrus> they asked me for wb rights
19:08:46 <elbrus> which I don't think I can/should be handing out
19:08:57 <pochu> no
19:08:58 <elbrus> I pointed them at wanna-build team
19:09:05 <pochu> that comes up every now and then
19:09:33 <ginggs> can i ask why it could be a problem?
19:09:57 <pochu> iirc it's been agreed that an automated solution would be accepted, for haskell, ocaml, rust, go... but nobody has worked on it yet
19:10:01 <elbrus> I guess: with power comes responsibility
19:10:21 <pochu> (well we the list of packages needing binnmus is already automated, but not the wb side)
19:11:14 <elbrus> pochu: I have always assumed you already had scripts in place to be able to do all those transitions in the right order
19:11:31 <pochu> nah :(
19:11:45 <elbrus> Sebastinas: also doing things by hand?
19:12:03 * elbrus started on some script based on the ben output (web scraping)
19:12:33 <elbrus> but it has been a while since Sebastinas and ginggs became active on that front
19:12:54 <Sebastinas> For ordering I rely mostly on ben.
19:13:07 <Sebastinas> And then feed a dumb script with source package names.
19:13:23 <elbrus> right, but I guess with a bit more integration, we can generate the wb commands from ben output
19:13:32 <pochu> would be better to have ben write some machine readable files. it already makes one for tracker.debian.org, we'd just need some other information
19:13:44 <elbrus> exactly
19:14:14 <elbrus> I don't mean ben creating the wb commands, but just better output than the web site
19:15:02 <elbrus> mehdi_ said he would take bugs filed against ben and try to improve it
19:15:22 <elbrus> so, I guess we could just ask on that front
19:16:08 <elbrus> anybody willing to take an action on this front?
19:16:53 <Sebastinas> I can take a look at it.
19:17:38 <elbrus> #action Sebastinas see if an improvement bug for ben can be created to provide better machine parsable output
19:17:54 <elbrus> something like that?
19:18:21 <elbrus> anything more on transitions?
19:18:28 <pochu> not from me
19:18:43 <elbrus> nodejs?
19:19:03 <elbrus> blocked on loads of autopkgtest
19:19:08 <Sebastinas> elbrus: Yes, sounds good. Some yaml file with the data could already be enough to help on the front
19:19:10 <elbrus> not seeing much happening
19:20:07 * elbrus will file some more regression bugs for that transition
19:20:23 <elbrus> next topic?
19:20:38 <elbrus> #topic Release architecture qualification follow-up
19:20:52 <elbrus> thread started at https://lists.debian.org/debian-release/2020/05/msg00089.html
19:21:35 <elbrus> as said, I can mostly reuse the mail from nthykier from last release
19:21:46 <elbrus> does anybody have more to add?
19:22:28 <pochu[m]> I wouldn't like to remove architectures for the sake of removing them
19:22:48 <elbrus> me neither
19:23:15 <elbrus> and YunQiang Su promised faster mips*
19:23:33 <elbrus> mipsel
19:23:39 <pochu[m]> If they have hw and users and we can reasonably support them then I'd keep what we can. Of course if there are valid concerns from the relevant teams then we'd hear them
19:23:54 <pochu[m]> So yeah that call makes sense
19:24:31 <elbrus> the point of course is that "reasonably" depends on who you ask
19:25:04 <elbrus> e.g. bunk raised an issue for s390x as the last big endian release architecture
19:25:05 <pochu[m]> We had a discussion about automating the process. Defining some criteria that would need to be met, and if it wasn't for some amount of time the arch would be removed. Tfheen volunteered to help but then buster got released and it probably became low prio
19:25:53 <elbrus> jcristau: said last time we discussed this something along the lines of "difficult decisions are difficult"
19:26:19 <pochu[m]> That itself doesn't sound like an issue
19:26:33 <elbrus> a bit of automation helps for making it more objective, but the criteria remain ...
19:27:34 <pochu[m]> In the end we may need to make an executive decision if we don't have a better way
19:27:43 <pochu[m]> Just like it happened in Vancouver :p
19:28:19 <kibi> :)
19:28:47 * elbrus has heard the term vancouvered, not as a great name
19:28:55 <pochu[m]> Whatever we do, some people will be unhappy
19:28:59 <elbrus> that
19:29:29 <pochu[m]> So I'd say let's send that call to relevant teams, and consider and weigh the pros and cons
19:29:38 <elbrus> #action elbrus send release architecture qualification call to the related teams
19:29:42 <elbrus> there
19:30:01 <pochu[m]> thanks!
19:30:06 <noahm> What are the relevant teams in this case?
19:30:18 <ansgar> The mail refernce said mipsel has the lowest ram limit?  What is it out of curiosity?
19:30:31 <pochu[m]> Wanna build, dsa, security, kernel
19:30:44 <elbrus> DSA, security, gcc team, glibc team
19:30:52 <noahm> makes sense, thanks
19:31:07 <elbrus> let's join those
19:31:13 <pochu[m]> and toolchain yeah
19:31:48 <elbrus> #topic Should autopkgtest regressions be RC for all release architectures?
19:31:52 <elbrus> ginggs ^
19:32:08 <elbrus> https://salsa.debian.org/release-team/release.debian.org/-/merge_requests/7
19:33:00 <elbrus> no ginggs anymore?
19:33:09 <ginggs> still here :)
19:33:20 <pochu[m]> Where are we running autopkgtests these days?
19:33:21 <elbrus> take it away
19:33:29 <elbrus> arm64 and amd64
19:33:29 <pochu[m]> Or is that theoretical?
19:33:43 <pochu[m]> So it's a no op atm?
19:33:43 <ginggs> it's theoretical
19:33:48 <elbrus> we have some ppc64el workers, but not enough for unstable-to-testing
19:33:58 <ginggs> as in the test are not automated
19:34:14 <elbrus> you can run it on porterboxes
19:34:23 <ginggs> but if someone finds a regression (or it comes from ubuntu)
19:34:26 <elbrus> and Ubuntu has more archs of course
19:34:31 <pochu[m]> I wouldn't change that right now. I'd rather get them running first, then add them as blocking when reasonably ready
19:34:40 <ginggs> and it can be reproduced e.g. on a porterbox
19:34:55 <ginggs> then can a bug be filed, and should it be RC?
19:35:08 <elbrus> bug can be filed
19:35:15 <pochu[m]> E.g. if I don't think it would be a great idea if mipsel gets added and lots of packages become insta RC
19:36:06 <ginggs> well, if someone finds a mipsel FTBFS, it is RC
19:36:09 * elbrus likes the idea of adding archs first and *then* declaring regressions RC
19:36:28 <elbrus> but that's because the package has to be able to build
19:36:41 <elbrus> to be in the release
19:36:46 <ginggs> on the flipside, often an autopkgtest regresses, and then we find out later it's actually a FTBFS
19:37:06 <ginggs> i.e. the autopkgtest was an early warning
19:37:10 <elbrus> I am very much not against fiing bugs
19:37:24 <elbrus> maybe even important
19:37:30 <elbrus> but not yet RC
19:37:54 <elbrus> but if other people like the idea of ginggs, I'm fine either way
19:38:28 <ginggs> just to reiterate, i'm only talking about regressions
19:38:54 <elbrus> as opposed to what we state about arm64 and amd64
19:38:58 <pochu[m]> I'm fine with that
19:39:00 <ginggs> whereas, if i understand correctly, any failure (old or new) is RC on arm64 and amd64
19:39:00 <elbrus> those must pass
19:39:36 <pochu[m]> They block testing migration atm right? So that effectively makes them RC bugs
19:40:20 <elbrus> regressions, yes
19:40:28 <elbrus> for amd64 and arm64
19:40:47 <ginggs> right, but policy says all failures are RC?
19:40:53 <elbrus> new tests that fail are also "regressions"
19:41:30 <elbrus> yes, we agreed on that (all failures are RC) for amd64 and arm64
19:41:33 <ginggs> what about old tests that always failed?
19:41:44 <elbrus> on amd64 and arm64: RC
19:41:57 * elbrus has been filing several bugs like that
19:42:08 <elbrus> just not a whole lot
19:42:09 <ginggs> understood, but those don't block migration?
19:42:18 <elbrus> no
19:42:41 <elbrus> just like RC bugs that are not regressions also don't block migration
19:43:25 <ginggs> ooo, i think i get it now
19:44:43 <elbrus> so, you want to change your proposal, or it stands?
19:45:00 <ginggs> i'm clearer now on amd64 and arm64, but still think regressions on other release architectures should be RC
19:45:28 <pochu[m]> Hmm yeah regressions would be fine
19:45:53 <elbrus> as said, I can live with it
19:46:02 <elbrus> anybody else?
19:47:36 <elbrus> #agreed autopkgtest *regressions* are RC on release archs, merrily failing on anything but arm64 and amd64 is not
19:48:07 <elbrus> ivodd: are you in?
19:48:16 <kibi> /C
19:48:20 <kibi> gah. :)
19:48:32 * elbrus though about discussing "point release process"
19:49:06 <elbrus> if not, we'll leave it till next time
19:49:22 <elbrus> #topic AOB
19:49:52 <elbrus> anybody?
19:50:35 <elbrus> #topic Next meeting
19:50:46 <elbrus> #info Next meeting is 22nd July at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics)
19:51:20 <elbrus> #endmeeting