16:00:37 #startmeeting FESCO (2016-10-14) 16:00:37 Meeting started Fri Oct 14 16:00:37 2016 UTC. The chair is paragan. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:37 The meeting name has been set to 'fesco_(2016-10-14)' 16:00:37 #meetingname fesco 16:00:38 #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann 16:00:38 #topic init process 16:00:38 The meeting name has been set to 'fesco' 16:00:38 Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh 16:00:54 morning 16:00:59 hi 16:01:05 morning 16:01:06 .hello pnemade 16:01:07 paragan: pnemade 'Parag Nemade' 16:01:29 .hello churchyard 16:01:30 mhroncok: churchyard 'Miro Hrončok' 16:01:33 * nirik has a hard stop at 17UTC today 16:01:48 .hello maxamillion 16:01:49 maxamillion: maxamillion 'Adam Miller' 16:01:52 .hello cstratak 16:01:53 cstratak: cstratak 'None' 16:02:08 .hello nb 16:02:09 nb: nb 'Nick Bebout' 16:02:43 okay we are 5 members now here 16:03:49 lets start 16:03:56 #topic #1626 Release blocking deliverables for Fedora 25 16:03:57 .fesco 1626 16:03:57 https://fedorahosted.org/fesco/ticket/1626 16:03:58 paragan: #1626 (Release blocking deliverables for Fedora 25) – FESCo - https://fedorahosted.org/fesco/ticket/1626 16:04:27 From https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora25 ,I see that only KDE SIG remain to reply. 16:04:59 Do we need to wait for their reply? or just close the ticket with the existing deliverables information for KDE SIG on that wiki page? 16:05:39 i'd propose only delivering what is listed but not blocking the release for it 16:05:40 I'm fine with closing it based on what we have now... 16:05:59 yeah, I'm good with closing 16:06:12 * kalev_ agrees 16:06:14 jwb: can you expand on that? you mean not blocking on kde because they didn't answer? or ? 16:06:24 nirik: correct. per my comments in the fesco ticket 16:06:42 if nobody feels responsible enough to reply to an email, how is that a group that can warrant blocking a release? 16:07:44 Proposal: Accept the current status of Release blocking deliverables as given on its wiki page and close the ticket 16:08:00 I think this may partially also be because it was FESCo that originally said that the KDE live image should be blocking, and not KDE sig 16:08:22 so maybe they don't feel they have control over what is blocking and what not 16:08:38 paragn: +1 16:08:47 kparal: +1 16:08:50 err. 16:08:51 well, the query on the kde list was "hey, if this is wrong, let us know" 16:08:52 paragn: +1 16:09:13 IMHO next time we should definitely say "please answer and tell us what is release blocking" 16:10:11 paragn: ok, +1 16:10:19 that's a majority vote. move on 16:11:37 yeah, +1 sorry 16:12:08 I think paragan may have connection troubles 16:13:43 yeah, he is... 16:14:00 can someone else drive for a bit? he messaged me on internal rh irc that his connection is not working 16:14:38 paragan: https://paste.fedoraproject.org/450215/14764616/ is what happened in the mean time 16:16:57 #agreed Accept the current status of Release blocking deliverables as given on its wiki page and close the ticket (+6,0,0) 16:17:30 #topic #1635 F26 Self Contained Changes 16:17:30 .fesco 1635https://fedorahosted.org/fesco/ticket/1635 16:17:30 nirik: Error: '1635https://fedorahosted.org/fesco/ticket/1635' is not a valid integer. 16:17:38 .fesco 1635 16:17:40 nirik: #1635 (F26 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1635 16:17:41 oops. sorry about that 16:17:59 there's 2 self contained f26 changes... 16:18:10 bind 9.11 and openssh crypto policy 16:18:24 * nirik is +1 to both 16:18:24 is crypto policy really self contained? 16:18:34 * kalev_ is +1 to both as well 16:18:45 well, it's just adding it to openssh client... 16:18:52 ah ok 16:18:55 which is important granted. 16:19:00 right 16:19:09 +1 to both 16:20:05 +1 from side for both the changes 16:20:53 jwb: ? 16:21:10 +1 16:22:45 #agreed self contained changes approved (+5,0,0) 16:23:07 #topic #1634 EOL and vulnerable software 16:23:07 .fesco 1634 16:23:08 nirik: #1634 (EOL and vulnerable software) – FESCo - https://fedorahosted.org/fesco/ticket/1634 16:23:51 * mhroncok and cstratak here for questions about added pythons 16:24:25 * mhroncok also has a more general proposal (or a draft of one) 16:25:19 Florian Weimer's comment in the devel list thread pretty much sums up my thoughts on this 16:25:26 "Fedora relies on EOLed components pretty much across the system (including critical security functionality), so one more such package really isn't the end of the world. I think new packages should not be held to tremendously higher standards than existing packages." 16:26:32 well, in this case aren't these for helping people test against rhel python versions? cannot we keep the security fixes from rhel synced up with them? (or any other changes) 16:26:48 nirik: we are doing that for python26 16:26:57 I guess there's 2 parts here. 1) this specific case and 2) in general moving forward 16:27:09 mhroncok: great. 16:27:15 i can't help but wonder if SCLs would have helped here. 16:27:23 jwb: +1 16:27:26 I guess there is no rhel 3.3 python supported anywhere? 16:27:30 but not sitting on the package waiting for cves, but rather syncing it now and then or when somebody asks to 16:27:41 nirik, there is actually 16:27:43 nirik: nope, but myabe a scl is, cstratak might know 16:27:44 nirik: probably in Software Collections which are on a 3 year lifecycle 16:28:03 right. so it might be possible to sync now, but that support will end at some point 16:28:33 for what it's worth, I very much support the idea that Fedora should be a viable development system for targetting RHEL. if this means shipping more python versions, then this is what we need to do. 16:28:51 we also plan to keep the package only for time we consider it useful which might colerate with scl 16:29:06 after all, development is one of the Fedora Workstation official target areas 16:29:15 right, if people are no longer developing against it, it's not a very useful testing target 16:29:24 nirik, yep but it's not only developing for rhel. People might want to test their code on older versions for whatever reason, not nescessarily for rhel 16:29:42 * kalev_ nods. 16:29:48 for now, for example Openshift Online 2 has python 3.3 and no newer 16:30:11 I guess, thats seems pretty weird to me. "hey, lets see if my code works against this thing we will never ship or use" 16:30:16 also, I agree with nirik that there are 2 parts here 16:30:27 agreed with nirik also 16:30:47 nirik: well if you develop a library, you might want to make it work in more version than you need personally 16:31:09 mhroncok: if you had a more general proposal, perhaps we should have you update the ticket and devel thread with it and we can discuss more over the next week? or is there urgency to decide this? 16:31:34 I don't have a urgency, the packages are there 16:32:10 mhroncok: sure, but I wouldn't want to support an EOL version... what if you run into problems with the EOL version? nothing you can do and you just wasted a bunch of time you could have used to work on the supported cases. 16:32:30 we can't ship every version of every software that ever existed 16:32:40 we cannot 16:32:54 nirik, that's up to the packager though, no? 16:32:54 but we can ship a reasonable subset of pythons to make Fedora better for Python developers 16:33:01 i think perhaps we're talking about different EOLs as well 16:33:18 there's upstream's EOL and there's the end of support for a version in various distributions 16:33:19 cstratak: I guess thats what we are trying to decide here. ;) 16:33:28 this was just merged to Fedora developer portal (but not deployed yet) https://github.com/hroncok/content/blob/c893f742cad6458ba010748b3e1683dba5671b84/tech/languages/python/multiple-pythons.md 16:34:55 I understand we don't want a packager to go and package Python 1.0 to Fedora just for fun 16:35:10 that's why I have an idea for a porposal 16:35:19 EOL packages with known security issues will not be added to fedora, unless there's a good reason. workgroups and SIGs can propose exceptions (stating the good reason). if those packages are not packaged as a dependency, no other packages can require or buildrequire them (but they can suggest and recommend). such packages needs to be marked especially, according to a rule yet to be agreed on fpc level. if such package is a dependency, the entire 16:35:47 you got cut off 16:35:58 sorry? 16:35:59 "...dependency, the entire" 16:36:04 your message was truncated 16:36:10 mhroncok: irc buffer truncated your text 16:36:14 i see, sorry 16:36:24 the entire stack needs to be marked. 16:37:13 is testing against old versions the only case for this kind of thing? I guess it might be... 16:37:30 that's our reason for pythons 16:37:44 I don't know what other parties would like to have and why 16:37:49 proposal: more discussion on list/in ticket and revisit next week 16:37:59 I think I'd like the security sig to review any such proposals 16:38:02 nirik: +1 16:38:15 * nirik isn't sure how active our security sig is... but we can surely ask them 16:38:43 or RHEL security team members then if our security team isn't active 16:38:51 I think the security team has regular meetings 16:39:11 * nb not sure 16:39:25 nirik: +1 16:39:28 or maybe i've just seen stuff in #fedora-security-team 16:40:49 other votes? or did we lose quorum? 16:41:44 well either it's agreed and postponed or the quorum was lost and it get's postponed :) 16:42:04 yeah true enough. :) 16:42:17 #info will discuss more on list/ticket and revisit next week 16:42:28 thanks for coming mhroncok and cstratak. 16:42:28 thank you guys, see you next week 16:42:38 #topic Next weeks chair 16:42:44 who wants it next week? 16:42:47 see you 16:43:00 I can do it 16:43:10 maxamillion: thanks 16:43:16 #info maxamillion to chair next week 16:43:20 #topic Open Floor 16:43:30 I had one item: pagure migration... 16:43:41 if no one objects I can do that later today or this weekend. 16:45:10 sounds good to me 16:45:17 * nirik had nothing else 16:46:35 * nirik sets the quantum fuse(tm) 16:46:47 ok, thanks for coming everyone. 16:46:49 #endmeeting