19:00:41 #startmeeting 19:00:41 Meeting started Wed Sep 27 19:00:41 2017 UTC. The chair is pochu. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:21 o/ 19:01:21 #info Previous minutes at http://meetbot.debian.net/debian-release/2017/debian-release.2017-08-23-19.01.html 19:02:23 shall we start? 19:02:28 #topic buster planning 19:03:24 jmw: KiBi: jcristau: moo if you're around :) 19:03:46 nobody got an action for that, right? 19:04:37 I suppose things would look similar to previous freezes, only question is when to freeze, november of february... we moved the freeze to february to get an LTS kernel but that didn't happen in the end right? 19:04:47 s/of/or/ 19:04:48 adsb: moo 19:05:21 pochu: that was done for 4.10 which should have been LTS; but 4.9 was in the end. 19:06:23 KiBi: do we know if the plan still is to have the first release of the year an LTS? 19:07:17 pochu: I haven't followed such things; there's an ongoing KernelRecipes conf in Paris (27-29), maybe that's going to be mentioned; in which case jcristau might know 19:08:55 that may be important to decide when we want to freeze 19:09:52 (also busy doing urgent maintenance at the same time, apologies for possible delays…) 19:10:35 there's also the question of whether we want to change some things 19:10:49 e.g. maybe the three month delay between transition freeze and full freeze is too much? 19:10:59 for stretch we had 19:11:06 nov 5: transition freeze 19:11:13 dec 5: 10-day migrations 19:11:27 jan 5: soft freeze (no re-entry, no new sources) 19:11:36 feb 5: full freeze 19:13:07 I had the feeling that it was too long, and maybe we could shorten it unless we think those 3 months help... e.g. we could make transition freeze and 10-day migrations happen together, next month soft freeze and next one full freeze 19:13:29 pochu: sgtm :) 19:14:04 other ideas to (try to) reduce the freeze? auto-remove key packages? :P 19:14:21 Have you guys ever thought about a "fake" freeze, like in Ubuntu, where you say "we're frozen now", but don't freeze migration? 19:14:37 I sent a proposal to team@ about that I am looking for feedback on 19:14:57 nthykier: ah right. sorry I haven't managed to read that :( 19:15:28 juliank: not sure how that works. do you mean before the real freeze? 19:15:46 juliank: also how do you think that would help? 19:16:29 pochu: It might reduce the number of unblock requests at an early freeze stage. 19:17:05 Not sure how much of a problem these are, though. 19:19:11 I think we managed pretty well. targeted fixes and point releases were reviewed in a timely manner in general. bigger releases didn't make much sense during the freeze and they tended to get ignored in general (I guess we subconciously avoid nacking them to avoid getting flamed) 19:20:00 besides that's probably the soft freeze right? we're in the process of freezing there, with the transition freeze etc, but there's no actual block hint for testing migration 19:20:34 Yeah, it's essentially soft freeze with a "please only upload bugfixes from now on" message 19:20:38 so any update can get in as long as it fullfils the usual prerequisites 19:21:08 ok. we don't say that for the soft freeze, or maybe don't say it too much, but I'm not sure it's much of a problem 19:21:45 I think the freeze is delayed by RC bugs that have been in testing for months prior to the freeze, but are largely ignored until we are forced to look at them 19:22:08 (and by we I mean the project, not just the RT) 19:22:22 or the number of bugs that are first filed after the full freeze start (c.f. the bug graph for Feb 2017) 19:22:41 hmm yeah, we need to do much better wrt that this cycle 19:23:08 many of those bugs were for package rebuilds and other general checks that could have happened way earlier 19:23:27 (rebuilds are an ongoing effort, but some of the other bugs happened once during the freeze) 19:24:57 #agreed have QA MBFs done before the freeze and not during it or too close to it 19:25:52 #idea maybe postpone the transition freeze by a month and have it with the 10-day migration stage to reduce the overall duration 19:26:02 alright anything else? 19:26:19 Not from me :) 19:27:12 alright let's move on, actual dates will have to wait (possibly for the sprint) 19:27:20 #topic transitions 19:27:30 that's for me I guess :) 19:27:57 nothing big going on atm 19:28:28 there's the openssl 1.0 removal, and the maintainer asked if the bugs could be bumped to RC 19:28:55 I'm tending to ack that, maybe asking him to warn the bugs first and then bump them a month later or so 19:29:11 we want openssl 1.0 out for buster, and the sooner we get things going the better 19:29:38 if we wait for the last moment to bump the bugs to RC then either this won't happen or some packages will get kicked 19:31:09 ok :) 19:31:55 What about r-base? I seem to remember someone reopening the transition bug saying that the API will be bumped? 19:32:01 #action pochu to ack the request to bump openssl1.0-rm transition bugs to RC 19:32:19 The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI 19:32:22 pseudo package from "r-api-3" to "r-api-3.4", as requested. 19:32:29 apparently it's already happened, yes 19:33:26 #action pochu to handle the r-base transition (tracker, binnmus) 19:34:14 #topic sprint 19:34:46 looks like we have rough consensus on meeting in Cambridge during the minidebconf-UK :) 19:35:05 and I'm afraid I won't make it, unless something happens in the meantime :( 19:35:18 boo 19:36:45 :) 19:36:50 maybe I could do Thu-Fri... we'll see 19:37:04 I'm not sure I'm useful in such a meeting… :( 19:38:27 KiBi: I'm sure you would :) 19:39:00 I've put the dates in the calendar at least, will see what happens with work etc. 19:39:16 at the very least we may need to pick a name for bullseye+1 :) 19:39:46 * KiBi checks whether strstretch is a TS character 19:41:09 alright anything else? 19:41:18 adsb, jcristau: do those dates suite you? 19:41:44 miniconf? I'm planning on being there, yeah 19:42:23 cool 19:42:34 no jcristau it seems 19:42:50 ok if there's nothing else let's move on 19:43:13 #topic Packages requiring instructions not present in an architecture's baseline (e.g. #857147) 19:44:11 I raised that. there are some packages that require instructions on some architectures not present in the baseline we support, and that causes problems, particularly if those are not just applications but e.g. toolchains 19:45:07 we have rustc not available because upstream targets a higher ISA on s390x than us, for example, but we had a problem with a toolchain that was available but was emitting instructions for a higher ISA (I think that happened with go?) 19:45:15 also for llvm/armel iirc, and that got fixed 19:46:22 so I'm not sure if there's much we can do here other than study problems in a case by case basis, but maybe we should have a policy that says these are RC unless they have an exception (or a -ignore tag?) 19:46:50 as some people argue that if the program emits an error and exits, then it's not RC 19:47:17 so do we think those are RC in general, or am I alone here? :) 19:47:19 that looks fishy to me 19:47:29 RC in general lgtm 19:47:56 esp. -mss* flags, people should just learn about multiple builds and optimized versions in specific directories, I guess? 19:49:07 I seem to recall a common counter argument being that without -mss* then it would be so slow that it is effectively useless. (To play the devil's advocate) 19:50:08 (I think the concrete case were some science related packages with some heavy math / computations) 19:50:14 doesn't seem convincing to me 19:50:52 these days GCC supports building some code with different instruction sets, picking the best one automatically at run time 19:50:56 they can just do the work or put their things elsewhere 19:51:53 pochu: iirc that was called "fat binaries" at some point 19:52:56 dkg: not sure; ISTR fat binaries being binaries for multiple archs. 19:53:02 Like x86+arm 19:53:12 ok so to end this discussion, let's say these are serious and if something else comes up again, we can revisit it :) 19:53:21 ack 19:53:23 s/serious/RC/ 19:53:26 ok 19:53:47 nthykier: unless you still disagree and maybe we postpone it for the sprint or for when it comes up :) 19:54:29 #agreed Packages requiring instructions not present in an architecture's baseline are RC-buggy 19:54:35 #topic AOB 19:55:20 (pochu: I have not decided my stance on the ISA problem yet; don't let that stop you thouh) 19:55:23 though* 19:55:32 AOB! 19:55:41 ok, always happy to revisit it :) 19:56:24 Reminder; I have a proposal for (hopefully) improving the RC bug counts outside freezes on team@ (as mentioned earlier in the meeting) 19:56:45 I would be happy to get feed back on it before I publish it to the general public for a wider discussion. 19:57:00 (and with that it is for me) 19:57:54 #info Please look at nthykier's proposal to improve RC bug counts outside the freeze and give feedback! 19:58:01 #topic Next meeting 19:58:05 #info Next meeting is 25th October at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics) 19:58:25 #endmeeting