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