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