19:00:41 <pochu> #startmeeting
19:00:41 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:21 <nthykier> o/
19:01:21 <pochu> #info Previous minutes at http://meetbot.debian.net/debian-release/2017/debian-release.2017-08-23-19.01.html
19:02:23 <pochu> shall we start?
19:02:28 <pochu> #topic buster planning
19:03:24 <adsb> jmw: KiBi: jcristau: moo if you're around :)
19:03:46 <pochu> nobody got an action for that, right?
19:04:37 <pochu> 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 <pochu> s/of/or/
19:04:48 <KiBi> adsb: moo
19:05:21 <KiBi> pochu: that was done for 4.10 which should have been LTS; but 4.9 was in the end.
19:06:23 <pochu> KiBi: do we know if the plan still is to have the first release of the year an LTS?
19:07:17 <KiBi> 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 <pochu> that may be important to decide when we want to freeze
19:09:52 <KiBi> (also busy doing urgent maintenance at the same time, apologies for possible delays…)
19:10:35 <pochu> there's also the question of whether we want to change some things
19:10:49 <pochu> e.g. maybe the three month delay between transition freeze and full freeze is too much?
19:10:59 <pochu> for stretch we had
19:11:06 <pochu> nov 5: transition freeze
19:11:13 <pochu> dec 5: 10-day migrations
19:11:27 <pochu> jan 5: soft freeze (no re-entry, no new sources)
19:11:36 <pochu> feb 5: full freeze
19:13:07 <pochu> 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 <nthykier> pochu: sgtm :)
19:14:04 <pochu> other ideas to (try to) reduce the freeze? auto-remove key packages? :P
19:14:21 <juliank> 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 <nthykier> I sent a proposal to team@ about that I am looking for feedback on
19:14:57 <pochu> nthykier: ah right. sorry I haven't managed to read that :(
19:15:28 <pochu> juliank: not sure how that works. do you mean before the real freeze?
19:15:46 <pochu> juliank: also how do you think that would help?
19:16:29 <juliank> pochu: It might reduce the number of unblock requests at an early freeze stage.
19:17:05 <juliank> Not sure how much of a problem these are, though.
19:19:11 <pochu> 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 <pochu> 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 <juliank> Yeah, it's essentially soft freeze with a "please only upload bugfixes from now on" message
19:20:38 <pochu> so any update can get in as long as it fullfils the usual prerequisites
19:21:08 <pochu> 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 <pochu> 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 <pochu> (and by we I mean the project, not just the RT)
19:22:22 <nthykier> 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 <pochu> hmm yeah, we need to do much better wrt that this cycle
19:23:08 <pochu> many of those bugs were for package rebuilds and other general checks that could have happened way earlier
19:23:27 <pochu> (rebuilds are an ongoing effort, but some of the other bugs happened once during the freeze)
19:24:57 <pochu> #agreed have QA MBFs done before the freeze and not during it or too close to it
19:25:52 <pochu> #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 <pochu> alright anything else?
19:26:19 <nthykier> Not from me :)
19:27:12 <pochu> alright let's move on, actual dates will have to wait (possibly for the sprint)
19:27:20 <pochu> #topic transitions
19:27:30 <pochu> that's for me I guess :)
19:27:57 <pochu> nothing big going on atm
19:28:28 <pochu> there's the openssl 1.0 removal, and the maintainer asked if the bugs could be bumped to RC
19:28:55 <pochu> 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 <pochu> we want openssl 1.0 out for buster, and the sooner we get things going the better
19:29:38 <pochu> 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 <nthykier> ok :)
19:31:55 <nthykier> What about r-base?  I seem to remember someone reopening the transition bug saying that the API will be bumped?
19:32:01 <pochu> #action pochu to ack the request to bump openssl1.0-rm transition bugs to RC
19:32:19 <pochu> The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI
19:32:22 <pochu> pseudo package from "r-api-3" to "r-api-3.4", as requested.
19:32:29 <pochu> apparently it's already happened, yes
19:33:26 <pochu> #action pochu to handle the r-base transition (tracker, binnmus)
19:34:14 <pochu> #topic sprint
19:34:46 <pochu> looks like we have rough consensus on meeting in Cambridge during the minidebconf-UK :)
19:35:05 <pochu> and I'm afraid I won't make it, unless something happens in the meantime :(
19:35:18 <adsb> boo
19:36:45 <nthykier> :)
19:36:50 <pochu> maybe I could do Thu-Fri... we'll see
19:37:04 <KiBi> I'm not sure I'm useful in such a meeting… :(
19:38:27 <pochu> KiBi: I'm sure you would :)
19:39:00 <KiBi> I've put the dates in the calendar at least, will see what happens with work etc.
19:39:16 <pochu> 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 <pochu> alright anything else?
19:41:18 <pochu> adsb, jcristau: do those dates suite you?
19:41:44 <adsb> miniconf? I'm planning on being there, yeah
19:42:23 <pochu> cool
19:42:34 <pochu> no jcristau it seems
19:42:50 <pochu> ok if there's nothing else let's move on
19:43:13 <pochu> #topic Packages requiring instructions not present in an architecture's baseline (e.g. #857147)
19:44:11 <pochu> 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 <pochu> 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 <pochu> also for llvm/armel iirc, and that got fixed
19:46:22 <pochu> 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 <pochu> as some people argue that if the program emits an error and exits, then it's not RC
19:47:17 <pochu> so do we think those are RC in general, or am I alone here? :)
19:47:19 <KiBi> that looks fishy to me
19:47:29 <KiBi> RC in general lgtm
19:47:56 <KiBi> esp. -mss* flags, people should just learn about multiple builds and optimized versions in specific directories, I guess?
19:49:07 <nthykier> 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 <nthykier> (I think the concrete case were some science related packages with some heavy math / computations)
19:50:14 <KiBi> doesn't seem convincing to me
19:50:52 <pochu> these days GCC supports building some code with different instruction sets, picking the best one automatically at run time
19:50:56 <KiBi> they can just do the work or put their things elsewhere
19:51:53 <dkg> pochu: iirc that was called "fat binaries" at some point
19:52:56 <KiBi> dkg: not sure; ISTR fat binaries being binaries for multiple archs.
19:53:02 <KiBi> Like x86+arm
19:53:12 <pochu> 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 <KiBi> ack
19:53:23 <pochu> s/serious/RC/
19:53:26 <nthykier> ok
19:53:47 <pochu> nthykier: unless you still disagree and maybe we postpone it for the sprint or for when it comes up :)
19:54:29 <pochu> #agreed Packages requiring instructions not present in an architecture's baseline are RC-buggy
19:54:35 <pochu> #topic AOB
19:55:20 <nthykier> (pochu: I have not decided my stance on the ISA problem yet; don't let that stop you thouh)
19:55:23 <nthykier> though*
19:55:32 <nthykier> AOB!
19:55:41 <pochu> ok, always happy to revisit it :)
19:56:24 <nthykier> 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 <nthykier> 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 <nthykier> (and with that it is </AOB> for me)
19:57:54 <pochu> #info Please look at nthykier's proposal to improve RC bug counts outside the freeze and give feedback!
19:58:01 <pochu> #topic Next meeting
19:58:05 <pochu> #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 <pochu> #endmeeting