15:00:01 #startmeeting FESCO (2019-03-11) 15:00:01 Meeting started Mon Mar 11 15:00:01 2019 UTC. 15:00:01 This meeting is logged and archived in a public location. 15:00:01 The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:01 The meeting name has been set to 'fesco_(2019-03-11)' 15:00:04 #meetingname fesco 15:00:04 The meeting name has been set to 'fesco' 15:00:06 #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:06 Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:08 #topic init process 15:00:11 .hello2 15:00:12 jforbes: jforbes 'Justin M. Forbes' 15:00:13 hello, party people 15:00:16 .hello psabata 15:00:17 contyk: psabata 'Petr Šabata' 15:00:20 .hello2 15:00:21 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:21 .hello2 15:00:24 bowlofeggs: bowlofeggs 'Randy Barlow' 15:00:47 morning 15:00:48 ain't no party like a fes-co party 15:00:49 hello 15:00:58 hay hoo 15:00:58 .hello2 15:00:59 otaylor: otaylor 'Owen Taylor' 15:01:00 .hello2 15:01:02 bookwar: bookwar 'Aleksandra Fedorova' 15:01:07 are all us US folks saving some daylight? :) 15:01:28 nirik: i've been stashing all my daylight away in an index fund 15:01:39 bookwar: we forgot to ask if current meeting time is acceptable. 15:01:41 so many people today! 15:01:58 zbyszek: works for me 15:01:59 bookwar: if possible, I think we should continue using this slot 15:02:05 OK, great. 15:02:17 okay 15:02:32 we don't have that many things today, which is great since this overlaps with the blocker meeting... 15:02:42 let's start with the new business 15:02:44 .hello2 15:02:45 bcotton: bcotton 'Ben Cotton' 15:02:48 you might even say this blocks the blocker meeting 15:02:51 #topic #2101 Fedora 30 incomplete changes 15:02:53 .hello2 15:02:54 .fesco 2101 15:02:54 sgallagh: sgallagh 'Stephen Gallagher' 15:02:56 https://pagure.io/fesco/issue/2101 15:02:57 contyk: Issue #2101: Fedora 30 incomplete changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2101 15:03:22 contyk: one by one? 15:03:24 shall we do them one at a time? or ? 15:03:29 welp, these things aren't done, so i guess we should just cancel fedora 30 15:03:35 yeah one at a time is good 15:03:43 bowlofeggs++ 15:03:43 bcotton: Karma for bowlofeggs changed to 16 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:03:50 stransky_: Ping? 15:03:58 sgallagh, yes 15:04:01 haha 15:04:04 yeah, let's go one by one 15:04:23 stransky_: https://fedoraproject.org/wiki/Changes/Firefox_Wayland_By_Default_On_Gnome has no update. Is it deferred? 15:04:24 stransky_: how's https://fedoraproject.org/wiki/Changes/Firefox_Wayland_By_Default_On_Gnome going? 15:04:36 it's written int he ticket 15:04:36 jinx! 15:04:40 sgallagh: it's waiting for F66 15:04:50 it's going well so far, week after ff66 should be ready for testing 15:05:09 Oh sorry. I missed the last update there. 15:05:19 my thinking: we have updates-testing enabled in beta so if we push this to updates-testing, we should get exposutre 15:05:24 zbyszek: I assume you mean FF66 and not F66 :-D 15:05:30 :D 15:05:31 haha 15:05:32 * bcotton notes that FF66 is scheduled for a week before the beta target 15:05:46 yeah this seems like a risky timeline 15:05:47 bcotton: Yes, that's relevant. 15:05:51 I'm testing F67.0a1, and it's come a long way, but there still are bugs... 15:05:58 sgallagh: :) 15:06:12 stransky_: possible to get a prerelease of it in sooner? or not worth it? 15:06:26 i think the question is: if we were to land it immediately after the beta freeze, is that too late? 15:06:39 yes, I'm working on the last importnat ones now. and yes, I can backport to 65 15:06:44 bcotton: Aren't we *in* Beta Freeze? 15:06:52 that does reduce testing somewhat... 15:06:55 sgallagh: yes, i mean after it thaws 15:07:02 this is going to be in updates-testing anyway, enabled by default, right? 15:07:11 if it's impornant it can be decided sooner, right after FF66 update 15:07:11 stransky_: when do you think you might have a build ready? 15:07:15 what's the difference in the testing amount it gets? 15:07:29 bcotton: sooner the better, IMO. I don't think there's much risk of this delaying the beta 15:07:32 mhroncok: Many people only test the Live 15:07:32 mhroncok: some people boot beta live media and test things and then move on... they never apply updates 15:07:47 some 15:07:48 if you say it has to be in FF66 release time the builds will be ready 15:07:55 for testing 15:07:58 in that case wee need an exception to make this land in beta, right? 15:08:06 mhroncok: Yes 15:08:07 yes, we already do. 15:08:17 Or declare it a "FESCo Blocker" 15:08:20 just making sure 15:08:21 But I'm not prepared to do that 15:08:48 speaking for myself, i'm not particularly keen on landing a change in a default, widely-used package this late in the process. but also we do it a lot so shrug 15:09:10 it's just a web browser 15:09:17 exactly :D 15:09:25 stransky_: The fallback plan is going back to the X version for Final, right? 15:09:32 I'd be ok with leaving it to the FE process... the sooner there's a build to propose the more likely it would be to get approved... 15:09:32 sgallagh, sure 15:09:59 proposal... 15:10:07 I'll make sure the beta gets usable browser 15:10:11 of course 15:10:17 Proposal: if the F66 is ready at least before the first RC of Beta, it can be default 15:10:33 sgallagh: FF 15:10:35 well, or a build with the needed stuff backported? 15:10:35 stransky_: how exactly 15:10:39 what do you mean by ready? ;) 15:10:39 heh, yes 15:10:50 stransky_: we either put it in beta for testsers 15:10:55 Built and in Bodhi 15:10:55 stransky_: or not 15:10:57 sgallagh: s/F66/the change/ ? 15:11:07 there are known bugs which need to be fixed 15:11:10 bowlofeggs: Sure 15:11:24 sgallagh: +1 from me 15:11:31 So there are two issues: whether to update to FF66 (which I think is pretty safe), and whether to switch go wayland by default (which is much more risky...) 15:11:33 well, so that bypasses the normal process? 15:11:41 Patch Proposal: "If the Firefox Wayland Change is ready for testing in time for the first RC of Beta, it can go in" 15:11:56 sgallagh: +1 15:11:58 +1 to the patched proposal 15:12:02 sgallagh: +1 15:12:03 +1 15:12:05 sgallagh: +1 15:12:06 +1 15:12:30 who decides it's ready? 15:12:40 I think the right contingency plan will be to simply switch the default, but keep FF66. 15:12:42 nirik: Change proposer 15:12:48 BZ tracked I guess is the first instance :) 15:12:49 zbyszek: Yes 15:12:51 zbyszek: +1 15:12:52 tracker 15:12:55 +1 (though I don't actually know the RC schedule) 15:12:56 zbyszek: yeah 15:12:57 counter proopsal: this change uses the normal FE process and if approved before beta can go in 15:13:11 otaylor: The RC schedule is "when the known blockers are cleared" 15:13:16 then QA and others can look and decide 15:13:32 nirik: I assumed it needs an excetpion to be ready to beta 15:13:46 if there is no exception / blocker, it cannot go to beta and hence is not ready 15:13:49 nirik: The FE process can decide that "they would consider". 15:14:03 nirik: yeah i guess i assumed it was implied in sgallagh's proposal too - we could make it explicit though - +1 15:14:23 My proposal is "FESCo wants this in, if it's done in time" 15:14:47 perhaps I am nitpicking, but the proposal sounds like 'if the change owner says it's ok, it bypasses FE and blockers and goes directly in' 15:14:50 sgallagh: it wasn't done in time 15:15:10 which I don't think is a good way to do things. 15:15:16 certainly not 15:15:30 yeah i want it to go through the FE/blocker process 15:15:38 OK, let me try one more patch 15:15:55 nirik: i think we assumed the same thing as you've written, but your wording is better indeed 15:16:23 * nirik waits for sgallagh 15:16:26 Proposal: FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. 15:16:49 sure, +1 and thanks. 15:16:56 ack 15:16:59 +1 15:16:59 ...if it doesn't land in beta, it is deferred to F31 15:17:01 right? 15:17:04 mhroncok: Yes 15:17:07 +1 15:17:13 +1 15:17:15 sgallagh, nirik: does this mean that FESCo asks for this update to be included in F30 beta? 15:17:19 #info Firefox Wayland by default on GNOME -- FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. 15:17:23 zbyszek: no 15:17:24 sgallagh: +1 15:17:31 Proposal: FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. If it does not land in F30 Beta, this Change is Deferred to F31. 15:17:41 Just to be clear what we're agreeing to for the record. 15:17:47 okay 15:17:48 zbyszek: asks to be considered I guess? 15:17:50 #undo 15:17:50 Removing item from minutes: INFO by contyk at 15:17:19 : Firefox Wayland by default on GNOME -- FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. 15:17:52 sgallagh: +1 15:18:02 #info Firefox Wayland by default on GNOME -- FESCo would like to see this Change land if it would not delay the Beta release. The standard blocker/exception review will make the final call. If it does not land in F30 Beta, this Change is Deferred to F31. 15:18:08 next one 15:18:24 contyk: wait a moment please 15:18:34 * nirik has to step away for a sec 15:19:16 I'm confused, because we're in freeze now. So this change will NOT go in, because there's no RC bug to fix. 15:20:14 "During these times, builds will not be marked stable and moved from updates-testing to fedora (and hence included in the milestone release composes) except for those approved under the QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process." 15:20:47 isn't the second sentence assuming the FE process? 15:20:50 It was said that an exception would need to be filed 15:20:56 zbyszek: I have just proposed it for FE 15:21:42 https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles 15:22:16 It seems to be me that a big default browser update is nowhere near any of the listed cases. 15:22:19 the fix is reasonably small and testable 15:22:30 as contyk said, it's just a webbrowser 15:22:32 zbyszek: The review starts in 40 minutes in #fedora-blocker-review 15:22:46 ;) 15:22:48 If you want to argue that it should not be granted an exception, do so there, please 15:22:54 OK, I'm not convinced, but let's move on. 15:23:00 thanks 15:23:03 one question 15:23:22 do we say: we want this to be granted an exception? or do we say: we want the usual process to happen? 15:23:24 sgallagh: I think it *should* be granted an exception, but as a FESCo priority. 15:23:39 mhroncok: I think we want the usual process to happen 15:23:49 if it's not granted an FE, the change will not land 15:23:49 ok 15:24:04 ok, Make BootLoaderSpec-style configuration files the default? 15:24:07 The usual process should happen, but FESCo is indicating that we consider this valuable to the distro (but not enough that we want to block on it) 15:24:31 sgallagh: OK, but can we make this a formal statement? 15:24:36 contyk: There was some chatter about this in the Workstation meeting this morning 15:24:47 zbyszek: I think we did 15:25:10 "FESCo would like to see this Change land if it would not delay the Beta release." 15:25:15 Can we please move on? 15:25:23 Yes, please do. 15:25:37 the bootloader one got set to ON_QA 15:25:38 On the next incomplete change - The BLS change was complete (according to the owners), just not moved to ON_QA - I got javierm to move it this morning 15:25:39 sgallagh: what was the chatter this morning? 15:25:42 so i think we can move on 15:25:57 So it sounds like it is on track? 15:26:01 #info Make BootLoaderSpec-style configuration files the default should be ready now 15:26:07 Haskell GHC 8.4 and Stackage LTS 12 15:26:14 jforbes: I heard mention of upgrades having issues, but no specific examples 15:26:18 that one makes me sad 15:26:26 mhroncok: Which? 15:26:31 Haskell GHC 8.4 and Stackage LTS 12 15:26:36 so... IMHO we cannot just tag this in now. 15:26:43 it has to be an update and go via the process. 15:26:49 but it's not on any media I don't think 15:27:12 what's the issue? 15:27:12 They set their contingency deadline at *branch*, not Freeze, either. 15:27:21 sounds like we are waiting on the packager in that releng ticket? 15:27:33 well, now, but I just commented... 15:28:01 fairly the thing was requested before the beta freeze 15:28:07 quite late 15:28:22 yeah. 15:28:27 Contingency deadline: Before branching of F30 15:28:41 this should have been reverted 15:28:43 juhp: you around? 15:28:54 Is reverting an option at this point? 15:29:00 it's in a side tag 15:29:03 so yes 15:29:12 Then I think we should defer it. 15:29:13 nirik: 12:30am in japan 15:29:22 yeah, true. 15:29:27 Proposal: defer haskell update to F31 15:29:32 +1 15:29:37 +1 15:29:38 sgallagh: +1 15:29:46 0 15:30:11 +1 I guess... but it's such a leaf I don't think there would be much harm letting it land in f30... 15:30:12 * mhroncok has another proposal 15:30:21 #info Haskell GHC 8.4 and Stackage LTS 12 -- past contingency deadline, deferring to F31 15:30:28 -1, for the reasons that nirik stated 15:30:30 * mhroncok waits for this vote to finish 15:30:37 defer or leave for component owner to deal with updates? 15:30:58 I'd rather not push such a big change as updates at this point 15:31:17 same 15:31:29 proposal: put everything to a large bodhi update, let it go in after beta. it's a giant leaf 15:31:40 mhroncok: +1 15:31:47 Of course, we're probably going to rubber-stamp the usual post-Freeze GNOME updates, so I feel kind of hypocritical :-/ 15:31:49 we do larger updates in the middle of stable release 15:32:01 mhroncok: +1 15:32:03 exactly 15:32:08 0 15:32:43 I could see an argument for it being pushed as an update honestly 15:33:19 alright 15:33:22 #undo 15:33:22 Removing item from minutes: INFO by contyk at 15:30:21 : Haskell GHC 8.4 and Stackage LTS 12 -- past contingency deadline, deferring to F31 15:33:23 0 15:33:42 i'm ok with it being an update 15:33:44 (I don't like it, but not enough to stand in the way) 15:33:50 i feel like managing it as a "giant leaf" essentially equivalent to letting update go through after release 15:34:03 i would prefer a deferral, but i would approve it as an update too 15:34:05 #info Haskell GHC 8.4 and Stackage LTS 12 -- if the maintainer wants this change to land in F30, they need to push it as an update bundle, otherwise defer to F31 15:34:19 next one? 15:34:23 MongoDB removal 15:34:23 contyk: ack 15:34:38 mongodb removal is funny ony 15:34:51 if we say we deffer it, are we goign to add it back? probably not 15:35:49 I think the remaining deps should be treated as normal bugs. 15:35:50 yet the change owner is not very communicative, I remember the proposal being very brief and franky they just removed donẗ care about dependent packages 15:35:59 so, those packages... is the solution to remove them? or ? 15:36:13 mhroncok: Well, at the same time, upstream is actively hostile to distros :-/ 15:36:19 I agree 15:36:20 zbyszek: yeah, that seems reasonable. 15:36:28 there should have been a "Contingency mechanism": if packages were not adapted - they are removed as well 15:36:39 I can understand not wanting to deal with extra bureaucracy to STOP maintaining it 15:36:39 I guess I'd +1 what zbyszek said 15:36:42 i think we can just let FTBFS take it from here 15:37:11 I think so too 15:37:11 zbyszek: Make that a proposal? 15:37:15 bowlofeggs: runtime deps 15:37:28 fawkes-devenv 15:37:29 bowlofeggs: they may not be FTBFS, they may require mongodb as a runtime thing.. probably against fedora policy to runtime dep something not in the distro, but no mechanism there 15:37:41 mongo-tools is FTBFS 15:37:42 otaylor: I'm wornking on it 15:37:47 *working 15:38:04 fawkes is FTBFS 15:38:14 ok, zbyszek, make it a proposal 15:38:28 proposal: the Change is implemented, but some dependencies on removed packages remain. Those should be treated as bugs and resolved in the usual fashion. 15:38:32 yeah if they require it as a runtime we have no choice but removal 15:38:38 but these did show mongo as a build dep 15:38:39 zbyszek: +1 15:38:46 zbyszek: +1 15:38:49 +1 15:38:58 +1 15:39:01 bowlofeggs: fawkes-devenv-0:1.0.1-18.fc29.x86_64 is runtime, mongo-tools-0:4.0.4-4.20181124git0f0d866.fc30.src is build time 15:39:03 +1 15:39:06 _1 15:39:08 +1 even 15:39:10 +1 15:39:21 mhroncok: right, but isn't fawkes runtime *and* buildtime, meaning that FTBFS will find it anyway? 15:39:24 +1 15:39:30 jforbes: _1 is the most ambiguous typo you could have made :-P 15:39:37 indeed 15:39:39 #info MongoDB removal -- the Change is implemented, but some dependencies on removed packages remain. Those should be treated as bugs and resolved in the usual fashion. 15:39:46 glibc32 build adjustments 15:40:07 Categories: ChangeIncomplete 15:40:20 I think this is done, but looking 15:40:32 contyk: Looks like the releng change was done, but don't know if there were followup packaging changes after that 15:40:34 there isn't much in the bug 15:40:37 bcotton: is that category a mistake? 15:40:47 https://pagure.io/pungi-fedora/pull-request/636 was the releng change that blocked it going in for F29 15:41:14 mhroncok: category for what? 15:41:28 bcotton: https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments 15:41:42 yeah, the releng part is done... 15:41:52 mhroncok: yes it is 15:41:54 fixing 15:41:57 good 15:42:33 Given that this is a build-time only issue, I'm probably fine with landing this whenever it's done. 15:42:35 https://src.fedoraproject.org/rpms/glibc32/commits/master 15:43:00 yeah, it didn't get retired... 15:43:15 so it's not all done 15:43:25 I wouldn't change it at this point on f30 really 15:43:33 proposal: move to f31 15:43:41 +1 15:43:46 mhroncok: +1 15:43:53 +1 15:44:14 +1 15:44:26 +1 15:44:27 +1 15:44:37 +1 15:44:42 #info glibc32 build adjustments -- not ready, deferring to F31 15:44:51 Build non-RELRO ELF binaries with .got.plt isolation 15:45:22 contyk: 1 moment 15:45:27 same here I think 15:45:55 additional proposal for glibc32: there was no reply since we moved this to f30. needinfo the change owner to ack it as f31 change. if there is no reply until we evaluate this for f31, we cancel the change 15:46:12 mhroncok: +1 15:46:16 sure. +1 15:46:23 +1 15:46:23 +1 15:46:26 ack 15:46:29 #undo 15:46:29 Removing item from minutes: INFO by contyk at 15:44:42 : glibc32 build adjustments -- not ready, deferring to F31 15:46:29 +1 15:46:35 mhroncok: +1 15:46:44 #info glibc32 build adjustments -- not ready; there was no reply since we moved this to f30. needinfo the change owner to ack it as f31 change. if there is no reply until we evaluate this for f31, we cancel the change 15:47:03 I think the next one will be the same 15:47:29 +1 for the same proposal 15:47:38 +1 for the same resolution 15:47:39 yeah +1 for same 15:48:13 +1 15:48:17 +1 15:48:19 * bcotton has updated the glibc32 change page and BZ tracker 15:48:23 +1 15:48:26 +1 15:48:39 #info Build non-RELRO ELF binaries with .got.plt isolation -- also not ready; there was no reply since we moved this to f30. needinfo the change owner to ack it as f31 change. if there is no reply until we evaluate this for f31, we cancel the change 15:48:44 Reset locale if not available 15:48:53 * zbyszek is here 15:49:07 zbyszek: I really want this 15:49:25 So... it's a tiny change, and I hope it can still go in for F30. 15:49:27 zbyszek: is there a technical problem or just not enough time to finish in time? 15:49:29 I see that it is delayed, but why is it delayed? 15:49:44 ovasik said he'll build for F30. 15:50:00 I made the implemnetation late, my fault. 15:50:10 would that be an update or FE? 15:50:11 * bcotton has updated the non-relro change page and BZ tracker 15:50:44 I'll ask for a FE. 15:50:54 sounds acceptable to me 15:50:55 since this affects containers and such, I think we need to stick it in beta to actaully test it 15:51:00 Anything that changes the build flags should be scheduled ahead of a mass-rebuild, shouldn't they? 15:51:09 Especially ones for security benefits. 15:51:13 sgallagh: build flags? 15:51:38 * contyk doesn't think this is about build flags 15:51:47 sgallagh: off by one error... we are talking about reset locale now. ;) 15:51:50 maybe I'm misunderstanding 15:51:55 gah 15:52:08 * sgallagh in two meetings at once. Must have missed one 15:52:10 ok, same resolution as firefox? 15:52:26 mhroncok: seems reasonable 15:52:28 +1 15:52:28 mhroncok: ack, +1 15:52:30 zbyszek: can you please push this to rawhide at least ASAP? do you need help? 15:52:59 mhroncok: I didn't want to use pp privs to push this. I'll ask the maintainer again. 15:53:00 agree that we need it to be in beta, locale bugs are often most simple and most embarrassing at the same time :) 15:53:35 #info Reset locale if not available -- code ready but there's no build yet; we'll follow the standard fe/blocker process; if it doesn't land by beta, it will be deferred to f31 15:53:41 zbyszek: if you prep a src.fp.o PR, I'll kick ovasik to merge it 15:53:45 bcotton: should I open a new bug, or can I use the change tracking bug to nominate for FE? 15:53:47 okay~ 15:54:00 mhroncok: will do 15:54:19 we have six minutes; do we even want to start with the followups? 15:54:33 zbyszek: probibly a new one to avoid closing or messing with the change bug? 15:54:45 nirik: ok 15:54:50 don't we have 1 hour and 6 minutes? 15:54:53 IMHO at least. 15:54:54 contyk: yeah, let's use the time. 15:55:09 bowlofeggs: I think the blocker meeting is here 15:55:14 ah 15:55:15 okay 15:55:18 #topic #2096 F31 System-Wide Change: BuildRequires generators 15:55:20 .fesco 2096 15:55:21 nope... they have their own channel. 15:55:21 contyk: Issue #2096: F31 System-Wide Change: BuildRequires generators - fesco - Pagure.io - https://pagure.io/fesco/issue/2096 15:55:22 https://pagure.io/fesco/issue/2096 15:55:28 so I added my comment to this one 15:55:41 zbyszek: you can probably use the tracking bug for that. adamw will tell us if you did it wrong :-) 15:55:46 I think it'd be a nice feature but I'd rather improve the SRPM situation than make it worse 15:55:47 contyk: I hear your comments and I agree. do you think we can summarize it as a hard requirement? 15:56:17 well 15:56:54 ignatenkobrain's is also valid but you can regenerate the SRPMs quite easily 15:57:08 I'm not sure if that would be possible in this scenario; I suppose I could formulate it somehow... 15:57:15 I might suggest, there is still very active and useful discussion in ticket, and this is an f31 change, so not exactly timing critical. Perhaps defer a week instead of waiting for everyone to catch up on a book? 15:57:27 there's a lot of activity on this this morning which I haven't had time to digest... 15:57:31 .hello2 15:57:32 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:57:36 jforbes: agreed 15:57:36 jforbes: +1 15:57:48 ignatenkobrain: got to it in time ;) 15:58:14 I've got exit game posponed by 15 mins, so I have some time to answer any questions if you have 15:58:22 ignatenkobrain: we need to end this in one 15:58:36 so yeah, I'd also postpone this and continue in the ticket 15:58:53 I can define my SRPM requirements more formally in the ticket and perhaps we can come up with some more things we'd want 15:59:25 ok? ok 15:59:41 #info We'll continue the discussion in the ticket for another week. 16:00:00 we don't have any production-ready implementation, we are still discussing implementation design 16:00:08 good! 16:00:09 so it is right time to raise your concerns 16:00:25 and I'll be happy to make sure they are resolved before we get real impl 16:00:41 ah, the blocker review isn't here 16:00:44 so I think we can continue 16:01:13 #topic #2092 Fedora 31 schedule 16:01:16 .fesco 2092 16:01:17 contyk: Issue #2092: Fedora 31 schedule - fesco - Pagure.io - https://pagure.io/fesco/issue/2092 16:01:18 https://pagure.io/fesco/issue/2092 16:01:25 bcotton: what what what'd i do 16:02:14 adamw: the question was whether to submit an FE using the change tracker bug or if a new bug should be created 16:02:24 the schedule is technically approved already, right? 16:02:59 bcotton: i wouldn't use the change tracker bug, because to close out the FE process we have to actually close the bug, but the change tracker bug shouldn't necessarily be closed just for whatever work occurs at beta, right? 16:03:06 we would still want the tracker bug open at final 16:03:13 ooh, good point. zbyszek^^ 16:03:15 adamw: thanks, I'll open a new bug. 16:03:19 npnp 16:03:38 mhroncok: counting you as +1, we're at (+4, 0, 0) 16:03:50 seems suboptimal, but okay 16:03:54 mhroncok: i'm acting like it is, but the schedule can always be changed later if need be :-) 16:04:43 zbyszek: yes, I'm +1 16:05:19 +1 to schedule 16:05:51 * zbyszek is still +1 16:05:57 +1 to schedule 16:06:05 * jforbes is still +1 16:06:34 * contyk is rather distracted now 16:06:44 +1 16:07:04 so that's... +6? 16:07:39 there are issues with python, is KDE release also a problem for that new release? 16:07:48 I have a quick note on this topic 16:07:58 bookwar: there are issues with python? 16:08:13 with python release date :) 16:08:14 GNOME 3.34 schedule was just published and 3.34.1 release is two days after proposed F31 final freeze 16:08:26 heh 16:08:33 everyhting is a bit later this time 16:08:46 would be slightly better to have F31 final freeze start 1 week later, but I suppose we can manage with a late FE too if it can't be done 16:08:51 and we cannot pospone f31 because holidays :( 16:08:51 maybe it is us who are too early? ) 16:09:02 Let's move the holidays. 16:09:10 I think Canada has them at a later date. 16:09:32 zbyszek: sure, at least we would maybe get some snow on xmas day in Prague 16:10:06 move to orthodox calendar.. 16:10:13 "cannot" is a strong statement, but postponing the fall release starts to get tricky very quickly 16:11:31 bcotton: currently we are not postponing explicitly but have big things land later, which means we are violating the schedule already 16:12:22 bcotton: can you add GNOME 3.34.1 to the F31 schedule please? Wed 2019-10-09 16:12:27 kalev: ack 16:12:30 thanks 16:14:05 bookwar: the difference is that landing things late may or may not push back dates. delaying the schedule means that slippages get us into the holidays and we run the risk of not having the people we need around to get the release out the door 16:14:46 anyway, the GNOME schedule conflict isn't the end of the world and if it's difficult to move the schedule we can work with that, just a bit more work for developement and QA to test the late freeze breaks 16:14:46 ok, back 16:15:12 wow, that list long... 16:16:13 Anyway, anything to do here? 16:16:32 sounds like there are some new items we need to consider and come up with a new schedule? 16:16:35 if I'm reading it right 16:17:02 the schedule is approved right now based on FESCo's voting policy 16:17:23 so Gnome3.14.1 and Python3.8 are treated as exceptions 16:17:29 or not? 16:17:33 contyk: I'd rather say "there are some external events which don't align well with our schedule, so we'll need to shoehorn some packages into the schedule." 16:17:35 there is no gnome change yet 16:17:37 so if someone wants a new schedule, they should tell me what they want and then we can decide if it's worth it 16:17:46 okay, thought we were waiting for that python thing 16:18:13 contyk: mhroncok was, but other people voted without him 16:18:16 if we can adjust in advance for those things I think that would be better than landing them after the freeze... 16:18:22 okay, let me review the count 16:19:15 okay 16:19:36 #agreed Fedora 31 schedule is APPROVED (+7, 0, -0) 16:19:49 #topic #2027 RFC: Module lifecycles 16:19:52 .fesco 2027 16:19:54 https://pagure.io/fesco/issue/2027 16:19:54 contyk: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027 16:19:56 if we move the release to January 2020, that would actually give some ammunition to the Python 2 deletionists :D 16:19:56 sgallagh, asamalik ^ 16:20:03 .hello2 16:20:04 asamalik: asamalik 'Adam Samalik' 16:20:07 mhroncok++ 16:20:07 bcotton: Karma for churchyard changed to 10 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:20:09 the new propsoal landed jjust before the meeting 16:20:14 I wasn't able to read it yet 16:20:15 * asamalik waves 16:20:37 I'm not up-to-date either 16:20:40 me neither 16:20:50 * jforbes either 16:21:02 This has been discussed (I think) two week ago and rejected by FESCo. We have discussed it on the Modularity WG meeting and sgallagh updated it. 16:21:21 Yeah it's been a last-minute update... 16:21:57 Sorry about that. I forgot to do it last week. 16:21:58 I'd propose giving FESCo another week to review it 16:21:58 So why are we discussing it right now? 16:22:06 but if you can summarize the changes now, that would also help 16:22:19 https://pagure.io/modularity/working-documents/c/dcd4d53df39b2500e19ad67b323fd90972046d94 16:22:42 The short version is we stopped trying to dictate an implementation, since that’s where FESCo got hung up. 16:22:45 * contyk hates horizontal scrolling 16:23:08 We now state that it must have a public API to retrieve the EOL data. 16:23:16 But not what must provide that API 16:23:20 Basically leaving out unnecessary implementation details, and rather stating requirements 16:23:26 that :) 16:23:40 ok to give it another week then? 16:23:48 contyk: sure 16:24:28 #info FESCo will review the new proposal within the following week 16:24:45 alright 16:24:49 #topic Next week's chair 16:24:50 "these values may be extended (enabling support on later releases), but may not be shortened." 16:24:55 that's creepy 16:25:08 anyway, will look trough it next week 16:25:14 any volunteers? 16:25:36 * mhroncok might not show up at all, not sure yet 16:25:37 I can do it 16:25:41 jforbes++ 16:25:44 jforbes++ 16:25:46 contyk: Karma for jforbes changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:25:52 #action jforbes will chair next meeting 16:25:57 #topic Open Floor 16:26:35 do we have a full list of things which are risky for current schedule (like Python3.8 and Gnome)? do we plan to build this list via Accepted Changes worklow? 16:27:39 I suppose that if somebody proposes a change for a new gnome version, they should provide the data points, plan and contingency if it doesn't release before finalf reeze 16:28:57 for Gnome it is already after the freeze 16:29:18 sure, so the change proposal must be accompanied with what's the actual plan 16:29:38 ok, so we would discuss it through the change acceptance 16:29:42 there's a pending update and a FE bug... 16:30:28 feels a bit weird to approve release schedule before knowing what is going to happen, but seems there is no much freedom anyway 16:30:43 ok, i am done with my question, thanks 16:31:34 * contyk nods 16:31:41 anything else for the open floor? closing in a minute if not 16:32:40 alright 16:32:44 #endmeeting