19:02:35 <elbrus> #startmeeting 19:02:35 <MeetBot> Meeting started Wed Feb 26 19:02:35 2020 UTC. The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:03:01 <elbrus> Previous minutes: http://meetbot.debian.net/debian-release/2019/debian-release.2019-10-23-19.36.html 19:03:08 <ginggs> o/ 19:03:13 <elbrus> #topic transitions 19:03:19 <elbrus> hi ginggs 19:03:33 <elbrus> that topic would be for you :) 19:03:43 <elbrus> if you can share the lastest status 19:04:02 <ginggs> sure 19:04:13 <ginggs> ruby2.7 is done 19:04:36 <elbrus> ack 19:04:55 <elbrus> llvm-defaults migrated, but not done, right? 19:05:03 <ginggs> gnuradio / volk / gr-osmosdr 100% done just waiting on migration of gr-osmosdr 19:05:39 <elbrus> acorn is all arch:all 19:05:51 <elbrus> is the maintainer aware? 19:06:19 <ginggs> llvm-defaults 9 - ghdl has ftbfs bug, gnome-builder/i386 has ftbfs bug 19:06:48 <elbrus> but overall, stuff is going reasonably smooth, right? 19:06:51 <ginggs> not sure of the status of rust-clang-sys, i didn't get an absolute answer from locutus 19:07:11 <ginggs> i think acorn is a bit of a mess 19:07:42 <elbrus> what's with rust-clang-sys? 19:07:58 <ginggs> src:acorn now builds node-debbundle-acorn which Breaks/Replaces/Provides node-acorn 19:08:23 <ginggs> but i don't think that's gonna work the way the maintainer intended 19:09:01 <ginggs> i'll file a bug asking for clarification if it's agreed that's the way forward 19:09:15 <elbrus> what's your worry? 19:09:39 <ginggs> the new acorn makes a bunch of packages non-installable 19:09:52 <ginggs> rebuilding doesn't help 19:10:00 <elbrus> because the Provides doesn't work? 19:10:42 <ginggs> hmm, i think there needs to be a transitional package, or everything needs a sourceful upload depending on node-debbundle-acorn 19:12:25 <ginggs> other than that, gnat-9 was slow to start, but there were many uploads yesterday and things are moving along 19:12:25 <elbrus> https://qa.debian.org/dose/debcheck/unstable_main/1582693202/amd64.html 19:12:45 <elbrus> shows some node-acorn stuff indeed 19:12:59 <ginggs> i wanted to start python3.8 as default as soon as gnat-9 is done 19:13:12 <ginggs> s/wanted/want/ 19:13:36 <elbrus> ack 19:15:08 <elbrus> ginggs: anything else (or more answers needed to the items raised)? 19:15:51 <ginggs> that's it, as far as current transitions goes 19:15:59 <elbrus> #topic Are our tasks well distributed? 19:16:35 <elbrus> as we announced the retirement of lots of members, I was wondering how our tasks are distributed 19:17:12 <elbrus> IIAC pochu was mostly doing transitions in the past, ginggs and I are helping there 19:17:40 <elbrus> adsb is doing SRM, I believe mostly alone 19:18:23 <elbrus> at this moment those seem the biggest continuous items to me 19:18:40 <elbrus> so, mostly, adsb, is the current situation OK? 19:18:56 <elbrus> how do others see this? 19:19:58 <adsb> more people doing stable stuff would never hurt, particularly now I'm juggling hats. but most of the time testing work is going to end up taking priority I guess, because that has day-to-day effects, rather than up to a couple of months delay 19:20:28 <elbrus> ack 19:21:12 <elbrus> should we actively seek more members? especially for SRM? 19:21:26 <elbrus> (we had one e-mail but no response to my reply) 19:22:05 <elbrus> I guess I can ping them 19:22:27 <elbrus> #action elbrus to ping the interested person 19:22:52 <ginggs> i think another call for volunteers in the next bits would be good 19:23:02 <elbrus> #undo 19:23:02 <MeetBot> Removing item from minutes: <MeetBot.items.Action object at 0x11c53d0> 19:23:22 <elbrus> #action elbrus to ping the interested person for the release team 19:23:50 <elbrus> #action elbrus add call for volunteers to the bits 19:24:51 <elbrus> kibi: are you fine in "your" corner of the teams work? 19:26:28 <elbrus> without reply, lets move to the next topic 19:26:30 <Sebastinas> I'd be willing to help out. 19:26:51 <elbrus> great 19:26:54 <adsb> my food appeared, so I might be less reponsive for the rest o fthe time 19:27:18 <elbrus> Sebastinas: shall be take that offer to e-mail or after this meeting? 19:27:56 <elbrus> #topic More bits 19:28:07 <Sebastinas> I'd prefer mail 19:28:10 <elbrus> ack 19:28:17 * elbrus too 19:28:36 <elbrus> last bits I told more bits were due 19:28:48 <elbrus> I want to announce our freeze policy soon 19:29:06 <elbrus> https://salsa.debian.org/ivodd/release.debian.org/-/blob/bullseye-date-proposal-ivo2/www/bullseye/freeze_policy.md has the latest draft 19:29:27 <elbrus> everybody (including all readers) are invited to judge for clarity 19:29:50 <elbrus> anything else for the bits? 19:30:18 <ginggs> depends on the next item :) 19:30:32 <elbrus> right 19:31:19 <elbrus> #topic Proposal to make a package's own autopkgtests blocking for its migration 19:31:45 <elbrus> even if it already fails in testing 19:32:10 <elbrus> autopkgtest failures are already RC (at least on amd64) 19:32:17 <elbrus> the idea being to prevent a possibly even more broken package from automatically migrating 19:32:28 <elbrus> idea from ginggs 19:32:50 * elbrus likes the idea 19:33:13 <elbrus> probably simple to implement 19:33:52 <elbrus> ginggs: do you care enought to try and come up with an MR against britney? 19:34:46 <ginggs> i can try 19:35:04 <ginggs> i have been rather busy at $DAYJOB 19:35:08 <elbrus> \o/ 19:35:12 <pochu> sorry guys I have to leave. I'll read the backlog later in case you have something for me o/ 19:35:18 <elbrus> o/ 19:35:25 <ginggs> pochu: bye! 19:36:11 <olly> does that include a package whose autopkgtests have never passed? 19:36:32 <elbrus> olly: I think that's the idea, yes 19:36:52 <elbrus> we want those failures fixed 19:37:05 <elbrus> or if that's too difficult, removed for now 19:37:10 <olly> fwiw, it was reasuring when I started adding them that there wasn't a penalty for having one that wasn't yet working 19:37:15 <olly> but I can see your point too 19:37:51 <olly> we don't want never-functioning ones around indefinitely 19:37:55 <elbrus> do you maybe have a link? 19:38:09 <elbrus> for where this reassuring came from? 19:38:25 <elbrus> but yes, there was a time where this was accepted 19:38:33 <ginggs> olly: if they failing, it's already failing, it's just that nobody's gotten around to filing a bug 19:38:35 <elbrus> we're now talking about ending that time 19:38:46 <olly> not a link, just a conclusion i came to 19:38:47 <elbrus> we already consider failing tests in bullseye as RC 19:38:55 <olly> i.e. reassuring to myself 19:39:09 <ginggs> i mean "if they are failing, it's already rc" 19:39:10 * jcristau isn't sure that's an improvement 19:39:14 <_rene_> I hope only amd64 counts? 19:39:36 <jcristau> it doesn't seem to be an incentive towards more tests 19:39:56 <_rene_> because stuff like "I am too slow and my timeout hits" would be extremely annoying and make people disable tests 19:40:30 <elbrus> I'm not sure that ignoring failures is better though 19:40:43 <elbrus> don't run them on those archs? 19:40:44 <_rene_> (if you didn't guess already: libreoffice/arm64) 19:40:48 <jcristau> i mean, we ignore build failures that aren't regressions 19:41:09 <elbrus> we don't ignore RC bugs that aren't regressions 19:41:11 <_rene_> elbrus: so I shouldn't run the tests which actually run the UI? 19:41:27 <jcristau> elbrus: for the purpose of migrating things we do 19:41:35 * _rene_ doesn't like that, but if that is the release teams wish.... 19:41:53 <jcristau> elbrus: for the purpose of possibly removing things we don't, but that's explicitly separate 19:42:05 <_rene_> (or even the "does this even start?" test. that builds parts of LO, but thankfully is inside the timeout.) 19:43:42 <elbrus> _rene_: I would love it when tests that are hitting timeouts on certain archs are disabled on those archs 19:43:57 <elbrus> but I see your point 19:45:42 <elbrus> ginggs: seems like we'll not do this for now... 19:45:52 <ginggs> to be clear 19:46:22 <ginggs> my original idea was not to include packages that had never passed 19:46:33 <elbrus> o, missed that 19:46:50 <ginggs> the scenario i envisage is as follows: 19:47:10 <ginggs> package has passing autopkgtests 19:47:20 <ginggs> a new upload breaks everything 19:47:32 <ginggs> some transient condition happens 19:47:51 <ginggs> the autopkgtests in testing fail (even once) 19:48:08 <ginggs> the broken package migrates automatically 19:48:20 <ginggs> that's what i'd like to avoid 19:48:57 <elbrus> there's a couple of things we could do 19:49:14 <elbrus> oops 19:50:27 <jcristau> ginggs: ok that makes more sense i think :) 19:50:28 <elbrus> well, so, the proposal could be to consider regressions differently for ones own package (like Ubuntu does for all tests) 19:51:21 <elbrus> that would be more involved to implement 19:51:35 <elbrus> but still doable I think 19:52:13 <elbrus> bonus, it gives maintainers more insentive to fix flaky failures 19:52:25 <elbrus> as they hinder ones own package more than other packages 19:52:46 <_rene_> that will give them just incetive to *disable* them 19:53:19 <elbrus> I don't mind disabling flaky tests that much 19:53:28 <elbrus> flaky tests are a waste of my time 19:54:14 <elbrus> #action ginggs to try and come up with MR to prevent packages regressing their own autopkgtest 19:55:19 <elbrus> #topic When to start architecture qualification; and who wants to drive that? 19:55:51 <elbrus> at one moment, we should start the architecture qualification, but I don't feel the right person 19:56:16 <elbrus> I think nthykier did some of that in the past, not sure about others 19:56:27 <elbrus> how shall we tackle this? 19:57:10 <elbrus> how far is the automated qualification? somebody was working on that, right? 19:57:15 <jcristau> it's always been a pain afaict 19:57:22 <elbrus> ack 19:58:03 <jcristau> i wouldn't hold my breath on automation, imo it's intrinsically a judgement call where reasonable people can disagree 19:58:25 <jcristau> automation can help but it'll only get you so far 19:58:37 <jcristau> it's just that making painful decisions is painful 19:58:44 <elbrus> I wasn't going to, I just recalled that there were discussions about it in the past 19:59:04 <jcristau> (others will probably disagree on this, too) 19:59:06 <elbrus> going to hold my breath 20:00:16 <elbrus> so, no answer now, shall I start a discussion about the process on mail? 20:00:37 <kibi> elbrus: sorry, got sidetracked 20:00:50 <elbrus> sure 20:01:41 <elbrus> #action elbrus to send mail about architecture qualification process 20:02:01 <kibi> elbrus: was thinking about a new release sometime soon, but been busy for now, and haven't checked with Sledge yet when we could do that 20:02:35 <elbrus> ack 20:03:10 <jcristau> elbrus: i suspect the main question re arch qual for bullseye is do armel and mipsel survive. 20:03:23 * elbrus thinks so too 20:04:00 <elbrus> removing mipsel had some push-back I heard 20:04:50 <elbrus> I think ivodd had some ideas on it too 20:05:05 <elbrus> I had one more topic, shall we briefly continue, or stop here? 20:05:30 <adsb> /o\ archqual 20:06:17 <elbrus> #topic When and how to deside on bookwork+1 name? 20:06:17 <ginggs> elbrus: go ahead 20:06:38 <elbrus> I guess around debconf is a good time to align on the next name? 20:06:59 <elbrus> depending on how many of us are going there? 20:07:34 <adsb> I'm not this year 20:07:38 <ginggs> have we ever asked for nominations or votes? 20:08:05 <elbrus> ginggs: I don't think we do that (or you mean in private?) 20:08:24 <elbrus> s//do / 20:08:33 <adsb> previously (at least for the time I've been involved) either the RMs chose directly or the team discussed it (usually in person) and then we picked amongst options 20:08:49 <adsb> sometimes with heckling from onlookers arguing for sheep or zurg 20:08:50 <elbrus> that's what I guessed 20:09:08 <ginggs> i meant in public, might be a fun thing, and be inclusive 20:09:52 <adsb> the argument is that choosing the name is about the one actual fun thing you get to do as RM :) 20:10:05 * elbrus needs to start looking the movies as preparation 20:10:14 <elbrus> that. 20:11:09 <elbrus> adsb: with RMs you mean pochu (according to the last delegation) 20:11:12 <elbrus> ? 20:12:07 <kibi> I think we've done that across all of the release team, as opposed to official RMs 20:12:17 <elbrus> great 20:12:24 * elbrus loves to help there :) 20:12:37 <adsb> it used to be RM, but there also used to not really be a team 20:12:45 * kibi already managed to get his beloved stretch chosen, so have fun :D 20:12:53 <adsb> Maulkin and I suggested names, then people grumbled about them :P 20:13:02 <adsb> for whichever one we named in new york 20:13:17 <ginggs> so how many will try to make debconf this year? 20:13:24 <ginggs> i do 20:13:25 <kibi> not me 20:13:32 <adsb> unlikely this year 20:13:52 <kibi> I hear there are several minidebconfs going on though ;p 20:13:58 <ginggs> ok, so elbrus and i will decide over some beers :) 20:15:19 <elbrus> #topic AOB 20:15:29 <elbrus> anybody? 20:15:40 <ginggs> nada 20:15:48 <adsb> nope 20:16:24 <elbrus> #topic Next meeting 20:16:35 <elbrus> #info Next meeting is 25th March at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics) 20:16:44 <elbrus> #endmeeting