19:05:46 <ivodd> #startmeeting
19:05:46 <MeetBot> Meeting started Wed Aug 28 19:05:46 2019 UTC.  The chair is ivodd. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:05:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:05:53 <ivodd> agenda at https://gobby.debian.org/export/Teams/Release/Agenda/irc-next
19:06:07 <ivodd> #chair elbrus
19:06:07 <MeetBot> Current chairs: elbrus ivodd
19:06:16 <elbrus> oops :)
19:06:21 <ivodd> #topic Actions and followups
19:06:40 <ivodd> both of these were about the buster freeze, so I guess we can just get them off the list
19:07:09 <elbrus> yes, my action was done
19:07:28 <ivodd> and the unblock queue is also cleaned up :)
19:07:31 <elbrus> nthykier asked over e-mail, but didn't receive much response as far as I know
19:07:59 <ivodd> let's move on
19:08:14 <ivodd> #topic Buster freeze items from last meeting
19:08:31 <ivodd> I don't think we need to say a lot about this. Buster was released :)
19:08:37 <elbrus> hurray
19:08:52 <ivodd> on to real items on the agenda
19:08:58 <ivodd> #topic Transitions
19:09:26 <ivodd> anybody around who has been keeping track of transitions?
19:09:33 <pochu_> not me :(
19:10:00 <adsb> mostly jmw recently
19:10:01 <pochu_> I had a look at the transition tracker and bugs today, saw that there's a perl transition request, but that's about it
19:10:04 <adsb> jmw: meeting poke
19:11:05 * elbrus noticed a weird one, volk, but thats a small one; the dev package got a rename so binNMU's dont work
19:11:14 <elbrus> hamradio area
19:12:14 <elbrus> move on?
19:12:19 <ivodd> yes
19:12:30 <ivodd> #topic RC of FTBFS
19:12:48 <pochu> I'll  look at the perl one and ack it if/when there aren't important conflicts
19:12:49 <ivodd> there have been a number of questions to the RT about when FTBFS bugs are RC, and when they are not
19:13:22 <elbrus> and currently a but a ctte as well
19:13:41 <ivodd> pochu: ok, thanks
19:14:02 <ivodd> so the question is: do we want to be the ones setting a detailed policy
19:14:29 <ivodd> my opinion would be: no. anybody think we should?
19:14:58 <ginggs> no
19:15:03 <elbrus> I sent my response to the list, I think it makes sense, but I don't think anybody has the tuits?
19:15:37 <adsb> so we decide on an individual basis, or expect someone else to write it?
19:15:53 <elbrus> adsb: you mean filed bugs?
19:15:57 <adsb> yeah
19:16:05 <ivodd> adsb: well, the next question on the agenda is: 'would we be ok with someone else creating such a policy'
19:16:08 <elbrus> so far, yes
19:16:08 <adsb> there has to be a line somewhere. you can't claim it's RC that QT won't build in 512MB of RAM or something
19:16:32 <adsb> elbrus: that wasn't necessarily a question that can be answered with a single "yes" :)
19:16:39 <pochu> I'm not sure I want others to write that policy. unless that policy is 'whether it builds on the official buildds', which kind of is the status quo
19:16:59 <elbrus> true, it was for the first part
19:17:22 <ansgar> adsb: As far as I understand we usually have packages that barely build on buildds (RAM, disk space).  So it would be unrealistic to have lower requirements than that...
19:17:38 <ginggs> i thinking building on the buildds is a reasonable place to draw the line
19:18:08 <elbrus> the same bug submitter has requested ruling on intermittent FTBFS (even on buildds)
19:18:09 <adsb> ansgar: sure, that doesn't mean people won't try
19:18:19 <pochu> and that line usually goes higher (in terms of RAM and disk space)
19:19:41 <pochu> the case of single CPUs is a bit special though. not sure I'd like that to be RC, I'm more leaning towards keeping it important
19:19:58 * elbrus too
19:20:11 * ginggs agrees
19:20:17 <adsb> sure
19:20:20 <ivodd> I agree about single CPU too
19:20:37 <ivodd> I guess we have a clear agreement about that part
19:20:53 <elbrus> but I think for "real" policy we should be doing a proper pro-con story, instead of just "leaning"
19:21:14 <pochu> as for RAM, disk, etc, you can't just force a minimum amount packages need to be able to build with
19:21:50 <elbrus> so, more on a case by case story
19:21:53 <elbrus> ?
19:22:30 <ivodd> I think case by case is the most realistic way forward for now
19:22:35 <pochu> more like "as much as it needs, as long as it's making a reasonable use of the resources and the buildds are configured properly, or DSA is happy to increase the resources as needed"
19:22:52 <pochu> so yes, case by case
19:22:55 <elbrus> some people won't like that :(
19:22:59 <pochu> no hard numbers
19:23:14 <ivodd> but do we agree on saying: single cpu is not rc?
19:23:37 <pochu> elbrus: do you mean whoever has a system with 2GB RAM and wants to rebuild webkit or GCC? there are things that we can't make work
19:23:55 <adsb> even if people on -devel insist otherwise
19:24:18 <pochu> ivodd: do we have a list of packages in the archive that currently fail to build on single core systems?
19:24:19 <elbrus> I mean that some people won't like it that we are not writing down hard numbers
19:24:25 <ivodd> #agreed we won't be setting a detailed policy about this now
19:24:48 <ivodd> pochu: I don't know if there is a list like that
19:24:54 <ivodd> but also, I don't want to spend time on that
19:24:59 <ivodd> I think it's a waste of time
19:25:08 <elbrus> I think Santiago has the list
19:25:08 <pochu> fair enough :)
19:25:34 <pochu> let's agree then and move one, and we can always come back in the future if there's new info
19:25:35 <ivodd> also, it should be clear that not every bug needs to be RC to be fixed
19:25:56 * kibi sneaks in
19:25:57 <ivodd> #agreed we don't consider FTBFS on single CPU RC at this point
19:26:05 <elbrus> I think the question the ctte asked us, if we want to be the body that sets policy
19:26:58 <elbrus> seeing the answers above, the answer is yes? except not in numbers, but slighly vague?
19:27:08 <ivodd> elbrus: something like that :)
19:27:27 <ivodd> can we move on?
19:27:42 <ivodd> #topic unblock reportbug template https://bugs.debian.org/883346
19:28:09 * elbrus likes to move that bug forward
19:28:20 <ivodd> elbrus: what's the question for the meeting?
19:28:45 <elbrus> I replied to the bug 1.5 months ago
19:28:58 <elbrus> shall I just go ahead, or do we need more discussion?
19:29:19 <ivodd> elbrus: I think you can just go ahead
19:29:34 <elbrus> Ok, I'll just propose a first version to reportbug
19:29:43 <elbrus> and we can improve it from there?
19:29:53 <ivodd> ok
19:30:03 <ivodd> #action elbrus to propose a first version to reportbug
19:30:04 <pochu> sounds good
19:30:09 <ivodd> thanks
19:30:16 <ivodd> #topic bullseye or Bullseye? https://bugs.debian.org/927680
19:30:26 <elbrus> yes
19:30:28 <pochu> the SRU one looks too long indeed. it'd be good to keep it concise
19:30:45 <elbrus> in the release notes, we did lower case
19:31:07 <pochu> AFAIR we've been recommending lowercase for a while
19:31:16 <ivodd> I'm fine with lower case
19:31:27 <ivodd> anybody disagree?
19:31:31 <ivodd> or DISAGREE?
19:31:37 <elbrus> :)
19:31:50 <elbrus> than I'll close the bug with this update
19:31:55 <ivodd> #agreed lower case
19:32:05 <adsb> we've conventionally always done lower-case for as long as I've been involved, and there was logic. but I've failed to find the specific history, other than the argument that they're not proper nouns, which I think came from vorlon originally
19:32:10 <ivodd> #topic WELCOME ginggs
19:32:11 <adsb> maybe he remembers :)
19:32:38 <elbrus> all links on respighi are lower case too :)
19:32:47 <adsb> well, yeah
19:32:59 <pochu> poor ginggs
19:33:01 <adsb> filesystem names generally are, in logical words :)
19:33:04 <adsb> heh
19:33:07 <adsb> *worlds
19:33:28 <adsb> well, we all know what happens to people who volunteer for the RT
19:33:42 <pochu> we become grumpy? :)
19:33:54 <elbrus> ginggs: you'll be helping transitions?
19:33:58 <adsb> fairly sure I was already grumpy tbf
19:34:02 <adsb> but sure :)
19:34:05 <pochu> :D
19:34:29 <kibi> (don't tell people that's a hard requirement)
19:34:55 <adsb> I don't think nthykier is grumpy enough yet
19:35:10 <adsb> but we digress
19:35:47 <ginggs> I think I could help with transitions, yes
19:36:18 <elbrus> jmw is most active at this moment I think, best coordinate the beginning with him I guess
19:36:48 <elbrus> ivodd: did you give me access to wb or how did we do that?
19:36:56 <pochu> ginggs: you can help with whatever you prefer
19:37:13 <elbrus> oh, sorry, yes, sure
19:37:18 <pochu> elbrus: you probably need a wb admin or dsa for that
19:37:19 <ivodd> elbrus: access to wb is given by DSA. It needs an rt ticket
19:37:22 * elbrus just quoted the e-mail
19:37:35 <ivodd> elbrus: in your case, I just submitted a ticket
19:37:44 <ivodd> I haven't done that for ginggs yet
19:37:54 <ivodd> #action ivodd to submit ticket to get ginggs wb access
19:38:02 <elbrus> about to ask...
19:38:56 <adsb> on a related note, one of us should reply to phil's comments on the haskell binnmu thread
19:39:22 <vorlon> adsb: that sounds like something I might've said, once ;)
19:39:33 <adsb> vorlon: :)
19:39:57 <adsb> phil> it's in reply to my saying wb access isn't up to us, but I don't really know whether any of the team-specific scheduling causes us any issues day-to-day
19:40:02 <adsb> vorlon: would you say it now?
19:40:11 <vorlon> adsb: yes
19:40:17 <adsb> fair enough, ta
19:40:31 <ivodd> #topic haskell binnmus
19:40:35 <vorlon> (and also, that it should be consistent with how the suite names are implemented in the archive, so unless you want to uppercase those...:)
19:40:41 <adsb> at least I'm not going crazy (in this specific instance)
19:41:09 <adsb> vorlon: yeah, that was one of my arguments, it's at least consistent
19:41:14 <ivodd> adsb: I'd prefer if this was handled in a somewhat similar way for all the static languages
19:41:24 <adsb> was that already on the agenda?
19:41:28 <adsb> must admit I hadn't checked
19:41:31 <adsb> -ETOOBUSY
19:41:36 <elbrus> no, just came in
19:41:43 <ivodd> adsb: no, but as you raised the topic...
19:41:48 <adsb> ++
19:42:13 <ivodd> adsb: what are you ++-ing?
19:42:24 <adsb> discussing it
19:42:35 <ivodd> ok
19:42:40 <pochu> I haven't read that thread yet, but IIRC I already proposed to run that automatically, and have some sort of mechanism (e.g. a lockfile) that we can use to stop it from running, e.g. due to another transition or whatever
19:43:11 <adsb> we don't get to decide who has access and what they do with it, but phil seems OK with us having a say on the basis that binNMUs are mostly a RT thing
19:43:36 <elbrus> that's how I read it as well
19:44:02 <elbrus> and he raise the issue of us stopping it as well
19:44:13 <pochu> ack. that's what I proposed on debian-wb-team@ a while ago when this was last requested by the haskell team
19:44:14 <ivodd> pochu: in that case I'd prefer that the relevant teams (for all the affected languages) generate lists of what needs to be binnmued
19:44:23 <ivodd> but that we actually run the script that submits them
19:44:23 <pochu> or by the golang people IIRC
19:44:33 <ivodd> so we can control priority, rate limiting of requests, etc
19:44:39 <ivodd> but that would need someone to do that
19:44:54 <adsb> "someone" is part of the current problem, for haskell at least
19:44:57 <pochu> ivodd: the scripts are already written and the nmus are already deprioritised
19:45:31 <pochu> see https://people.debian.org/~nomeata/binNMUs-haskell.txt
19:45:49 <ivodd> pochu: I'm aware of that
19:45:50 <pochu> for a year or two now, I've been the one scheduling those binNMUs when there were transitions
19:47:00 <ivodd> adsb: with 'someone', I meant someone from the RT
19:47:20 <adsb> sure, but it still needs manpower
19:47:29 <adsb> which we're also not great at sometimes
19:47:38 * elbrus wonders if he wants to volunteer at this moment
19:47:51 <adsb> ha
19:48:21 <elbrus> generating a cron to take that list is easy; but in a smart way....?
19:48:52 <pochu> we can say "yes we're fine, if you want it, work on it :P"
19:49:13 <ivodd> pochu: I'd prefer not giving every relevant team wb access
19:49:31 <ivodd> I'd prefer having them generate a list of packages that need to be rebuilt, and process them centrally
19:49:42 <pochu> ivodd: yes, that's what I mean
19:49:58 <ivodd> pochu: oh, ok, I misunderstood you
19:50:10 <pochu> by work on it I didn't mean "schedule the binNMUs", but "write the tool to automate it and we'll review it"
19:50:39 <pochu> but looks like we agree on automating this? if so we can move on
19:51:03 <ivodd> yes, I think we agree on the general idea, and we shouldn't discuss the details further now
19:51:10 <elbrus> ack
19:51:19 <ivodd> #topic How to handle open bugs on https://bugs.debian.org/release.debian.org
19:51:44 <elbrus> I raised this topic when there were also still a lot of transition bugs on the list
19:51:48 <elbrus> that's better now,
19:52:02 <elbrus> but the list at the bottom is still rather long
19:52:15 <adsb> we've made a good dent in the pu stuff recently too
19:52:16 <elbrus> but I guess it's the problem of all bug lists, right?
19:52:28 <elbrus> agree
19:52:39 <adsb> well, the requests. the tooling ones will mostly take a while, which is why they're in the BTS to start with
19:52:56 <adsb> also so that someone magically decides to contribute :D
19:53:39 <ivodd> I don't know if there is much more we can say about this in the meeting...
19:53:40 <elbrus> so the bugs are there to attract new team members?
19:53:56 <adsb> no, they're there to make sure we don't forget about them
19:54:28 <elbrus> but I wonder how good we are at closing stuff long fixed?
19:54:48 <adsb> for transitions, apparently not very
19:54:51 <adsb> jmw closed loads
19:54:58 <elbrus> anyways, I think indeed the list was longer when I added it to the agenda, lets move on
19:55:22 <adsb> there were definitely loads more outstanding transition and pu bugs around debconf
19:55:36 <ivodd> #topic Architecture qualification for bullseye
19:55:43 <ivodd> mips is gone
19:56:42 <kibi> well spotted by jcristau (IIRC): port diversity is shrinking; we might get some more arch-specific things that only hit a single arch
19:57:09 <kibi> (not specifically a release team topic, but felt like mentioning it anyway)
19:57:54 <ivodd> I don't know who put this on the agenda, but I don't think we can say a lot more on this topic right now
19:57:55 <elbrus> we should update https://release.debian.org/bullseye/arch_qualify.html
19:58:00 <kibi> by which I mean: 2019-08-22 11:18:54[ jcristau] hmm.  we're down to just s390x as BE arch in sid?
19:58:18 <elbrus> to remove mips
19:58:42 <ivodd> #action mips should be removed from https://release.debian.org/bullseye/arch_qualify.html
19:58:49 <elbrus> otherwise, is there stuff that needs there to be more in the "start of the release"?
19:59:08 <elbrus> ... state/
19:59:25 * elbrus doesn't know how that was handled in the past
19:59:39 <pochu> the arch_qual can be updated, but I wouldn't worry much about it at this point
19:59:48 <adsb> the general point that's been raised a few times is that leaving thinking about arch qual until later in the cycle tends not to be that useful in the end
19:59:51 <adsb> elbrus: "badly"
19:59:52 <elbrus> maybe add a disclaimer then?
20:00:13 <ivodd> elbrus: a disclaimer on that page might be good
20:00:32 <ivodd> also, probably removing some of the info until it is checked again, might be good
20:00:33 <pochu> Mithrandir volunteered to work on an architecture autoremoval tool :)
20:00:37 <adsb> we can make final decisions nearer the end, but could do with spotting and dealing with issues throughout the cycle
20:01:04 <adsb> pochu: he did, for the buster cycle. but ran out of time, because, well busy people are busy
20:01:09 <elbrus> #action elbrus refresh arch_qualify page
20:01:16 <pochu> adsb: tell me about it :(
20:01:27 <ivodd> ok, let's move on
20:01:30 <ivodd> #topic AOB
20:01:36 <ivodd> anything else?
20:01:45 <pochu> nope
20:02:09 <ivodd> #topic next meeting
20:02:25 <ivodd> are we sticking to 4th Wednesday 19:00 UTC?
20:02:38 <pochu> for now yes
20:02:40 <ivodd> that would be 25/9
20:02:47 <adsb> not sure anyone suggested better ideas
20:02:54 <pochu> a change should be proposed on the list with enough time for people to vote
20:03:05 * elbrus doesn't recall responses to nthykiers mail
20:03:05 <ivodd> #agreed next meeting 25/9 at 19:00 UTC
20:03:29 <ivodd> thanks everyone
20:03:31 <ivodd> #endmeeting