16:00:33 #startmeeting FESCO (2016-10-21) 16:00:33 Meeting started Fri Oct 21 16:00:33 2016 UTC. The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:33 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:33 The meeting name has been set to 'fesco_(2016-10-21)' 16:00:34 #meetingname fesco 16:00:34 The meeting name has been set to 'fesco' 16:00:34 #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann 16:00:34 Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh 16:00:37 #topic init process 16:00:56 hola 16:00:59 morning 16:01:01 .hello jsmith 16:01:02 jsmith: jsmith 'Jared Smith' 16:01:08 .hello maxamillion 16:01:09 maxamillion: maxamillion 'Adam Miller' 16:01:15 .hello pnemade 16:01:16 paragan: pnemade 'Parag Nemade' 16:01:30 .hello kalev 16:01:31 kalev: kalev 'Kalev Lember' 16:01:32 .hello churchyard 16:01:34 mhroncok: churchyard 'Miro Hrončok' 16:01:39 .hello cstratak 16:01:40 cstratak: cstratak 'None' 16:02:13 the agenda is pretty short for today (sorry again for getting it out so late, completely slipped my mind) 16:02:15 hi 16:02:54 alirght, let's get rolling 16:03:02 .hello sgallagh 16:03:03 sgallagh: sgallagh 'Stephen Gallagher' 16:03:04 #topic Follow Up Business 16:03:07 #topic #1634 EOL and vulnerable software 16:03:08 .fesco 1634 16:03:08 https://pagure.io/fesco/issue/1634 16:03:09 maxamillion: Issue #1634: EOL and vulnerable software - fesco - Pagure - https://fedorahosted.org/fesco/ticket/1634 16:04:07 this didn't really get anywhere last week, wasn't sure if we wanted to discuss more here or defer again? maybe bring it to a wider audience? $other (I'll admit I'm behind on devel list so if it went there, apologies but I didn't see any updates to the ticket) 16:04:30 no e-mail since last week 16:04:31 I haven't seen any further discussion 16:04:34 AFAIK 16:05:05 nope 16:05:11 * dgilmore feels if there is a need for such software there should be enough to make sure it is supported 16:05:43 alright, any proposals for a vote? 16:07:18 do we need fesco ticket for every such EOL software package entering into Fedora? 16:07:26 I don't think so we need it 16:07:34 paragan: I do not think so 16:08:18 paragan: in the case of the python stack that caused this ticket to be filed, Red Hat is uspporting the python internally, we can make sure to keep the version in Fedora in lockstep with RHELs 16:08:35 then people can test and develop coded against the same python they will use in production 16:08:36 I do think it's a case by case basis thing 16:08:41 Do we want to make that a policy? 16:09:21 I guess there's no way we could really enforce such a thing, though 16:09:41 proposal. if there is a compelling use case to have eol software it would mean that its being supported elsewhere, in which case we should be sure to work with the lesewhere to get fixes into fedora 16:09:48 sgallagh: not simply 16:10:00 because if people were to show up and want various versions of some scheme or lisp dialect available, given those language ecosystem's comparative popularity and vested interest from groups involved in Fedora, I think it would merit a discussion about support in the long term 16:10:01 well, EOL is probibly not well defined... 16:10:07 dgilmore: I like that phrasing 16:10:09 (just as an example) 16:10:13 nirik: +1 16:10:43 nirik: sure unsupported upstream? 16:10:45 I guess maybe we should make the distinction between "EOL by upstream" vs "Maintained by a downstream" 16:10:59 explicitly? 16:11:19 because a project that hasn't released anything in years might well be not supporting it anymore, but we don't know 16:11:30 proposal. if there is a compelling use case to have unsupported by upstream software it would mean that its being supported elsewhere, in which case we should be sure to work with the elsewhere to get fixes into fedora 16:11:39 (and we have many cases of those kinds of packages in fedora) 16:11:55 nirik: I guess what I'm saying is this: "Software may only be included in Fedora if someone, somewhere states they are maintaining ig" 16:11:56 *it 16:12:12 This might be Red Hat, Joyent, Sal's Pizza Parlor... 16:12:14 ok, could that someone be the fedora maintainer(s)? 16:12:20 dgilmore, while this might work for python I don't think it applied for the vast majority of EOL packages that are currently included in Fedora 16:12:20 (With no solid definition of "maintaining") 16:12:22 But a statement needs to exist. 16:12:32 nirik: I'm fine with that, as long as the explicit statement is made 16:12:51 cstratak: is there a list of EOl packages in fedora that dgilmore's proposal wouldn't apply to? 16:13:26 maxamillion, packages that are only maintained or "exist" in Fedora. Upstream is dead and they are not packaged somewhere else. 16:14:04 cstratak: perhaps, but to date the people maintaining it have commited to do so. the difference with python is that tehy said they would not, which I think is wrong given that there is ongoing work elsewhere to upstream. and many of the others may be getting security fixes in Debian or other distros 16:14:14 * mhroncok have seen plenty of those when porting stuff to python 3, but does not have an explicit list 16:14:22 in which case the debian and fedora maintainer should work together :D 16:14:33 cstratak: Honestly, there's no way to detect that. We have to trust our maintainers and the non-responsive maintainer policy to step in there. 16:14:56 sgallagh: +1 16:15:08 dgilmore, ehm I believe it has been explained numerous time that we are going to maintain the packages? 16:15:30 the main idea behinf that "no security fixes" thing in pythonXZ packages was to wanr users 16:15:30 * nirik is fine with this specific case with the pythons getting security/other updates from rhel, but I am not sure how to generalize some generic answer here. 16:15:35 cstratak: I left where the maintaince was happing necessarily broad to include anywhere else that is maintaing the same software 16:15:48 so that they should not use those in production 16:16:06 cstratak: thats not what was in the spec last I looked 16:16:22 if we say those packages are in sync with RHEL, everybody will try to use them in production 16:16:23 * dgilmore is still catching uip on many things after fudcon though 16:16:40 nirik: +1 16:16:43 mhroncok: and it may not be RHEL that we keep in sync with 16:17:20 we intedned to maintain those packaages, if somebody opens a bug in bugzilla or asks us to fix this or that 16:17:38 we didnẗ plan to fix CVE's automatically within minutes 16:17:47 %description 16:17:47 Python 3.5 package for developers. 16:17:48 No security fixes will be applied. 16:17:53 Python %{pybasever} package for developers. 16:18:09 thats the big button 16:18:09 yes, ans as was discussed on devel ML, this was unfortunate 16:18:20 and we are willing to change that wording after this discussion 16:18:58 mhroncok: debian, or gentoo ,or other distros may be doing security work if Red Hat is not 16:19:02 also just some extra info, me and mhroncok are also maintaining the RHEL equivalents stacks so it's not really a question if we want to maintain the packages or not, this has already been established by the ongoing discussions at the tickets and ML 16:19:24 if we are the only ones looking at some old piece of software, then I think it is fair to say we probably should not do it 16:20:03 well I have such packages already, where noone is looking at them 16:20:10 sorry, I had to step away for a bit -- I think it's probably fine to have packages in fedora that are EOL upstream, as long as there is someone committed to supporting them here downstream (the maintainer) 16:20:18 upstream is dead and I make sure that if a Fedora bug is filled, I fix it 16:20:18 I think the whole controversy here stemmed from the fact that the packages stated that they won't get security updates 16:20:23 proposal. if there is a compelling use case to have eol software it would mean that its being supported by other downstreams, in which case we should be sure to work with the other downstreams to get fixes into fedora 16:20:24 which is just against fedora's existing practices 16:20:28 if we have that, I think it should be fine to ship the python packages 16:20:45 kalev: exactly 16:20:49 kalev: +1 16:20:56 * nirik nods. 16:21:04 gahh 16:21:19 proposal. if there is a compelling use case to have unsupported upstream software it would mean that its being supported by other downstreams, in which case we should be sure to work with the other downstreams to get fixes into fedora 16:21:54 here fixes mean security fixes as well right? 16:22:03 mhroncok: cstratak: if you had not put in "No security fixes will be applied." no one would have batted an eyelid 16:22:08 paragan: yes 16:22:15 I know that now :D 16:22:35 It's this a more general case of "Packages in the fedora collection must be supported. If not upstream, but the fedora maintainer(s)"/ 16:22:36 ? 16:22:43 nirik: sure 16:23:19 would "Securty fixes might not be applied as fast as on the regural python packages" be better? 16:23:30 so perhaps we could just add that to https://fedoraproject.org/wiki/Package_maintainer_responsibilities ? or call it out better? 16:23:39 nirik: indeed 16:24:39 At the end of the day, all package maintenance in Fedora is voluntary. Sometimes it's subsidized by a company like Red Hat, but we've never given anyone promises about the speed at which we release updates. 16:24:52 sgallagh: +1 16:24:58 I could try and draft up a change there.... but I also won't be here next week. 16:24:58 that's right 16:25:17 there's no SLA on speed at which fixes/updates happen 16:25:22 but we'd still like to indicate somehow that it si not a good idea to use pythonXY package in production 16:26:41 I'd just be more verbose there and explain things... "These packages exist to allow fedora developers to test against RHEL or other long term downstream supported pythons. They are not a full python stack and if you wish to run your applications with them, see RHEL/CentOS/UbuntuLTS" 16:27:05 * kalev nods. +1 16:27:18 nirik: thanks, I'll put somehting like that in %description 16:27:39 nirik, +1 16:27:44 +1 16:28:14 of course we can't force people to use a package a particular way, but we can suggest/point them... 16:28:29 nirik: +1 16:28:38 so can we wrap this up? 16:29:13 seems we maybe want to make some changes in the packager responsibilities page to make things clearer 16:29:14 I think so, yes 16:29:15 how about we approve these and I draft a change for maintainer reposnsibilities... ? 16:29:23 nirik: +1 16:29:24 (these being pythonXY) 16:29:27 nirik: +1 16:29:38 and mhroncok and cstratak will update the text that caused all the noise 16:29:47 sure, I'll do it ASAp 16:29:51 nirik: sure 16:30:23 #action nirik to draft up a change for maintainer reposnsibilities 16:30:29 nirik: +1 16:30:57 #proposal accept pythonXY with wording changes in the description 16:31:08 dgilmore: +1 16:31:09 I am +1 16:31:12 dgilmore: +1 16:31:16 dgilmore, +1 16:31:40 +1 16:32:14 +1 16:32:31 maxamillion: I will let you wrap it up 16:32:47 jwb: jsmith: ? 16:32:55 didn't we just vote on this? 16:33:04 +1 16:33:19 jwb: it was not a formal proposal 16:33:57 I see jsmith +1'd nirik 16:34:07 alright 16:34:08 #agreed - accept pythonXY with wording changes in the description (+1: 7, +0: 0, -1: 0) 16:34:23 #topic New Business 16:34:25 #topic #1635 F26 Self Contained Changes 16:34:26 .fesco 1635 16:34:26 https://pagure.io/fesco/issue/1635 16:34:27 maxamillion: Issue #1635: F26 Self Contained Changes - fesco - Pagure - https://fedorahosted.org/fesco/ticket/1635 16:34:34 thanks all 16:35:22 new ones looks like Odoo and PHP 7.1 16:36:13 +1 to both I guess. Odoo makes me want to revisit what a Change is tho... 16:36:22 what nirik said 16:36:34 yeah 16:36:37 I think that's fair 16:36:43 +1 to both for me as well 16:36:50 I'm +1 to PHP but -1 on Odoo 16:36:54 Odoo is not a Change 16:37:09 In the sense that I don't have a problem with its inclusion, but it's not a Change 16:37:31 * kalev concurs. 16:37:57 +1 16:38:21 +1 to PHP, -1 to Odoo as I don't think it qualifies a Change 16:38:26 ha, it's open core too... ick 16:38:37 Proposal: FESCo advises that Odoo not be listed as a Change, but the maintainer is free to add Odoo to the repositories 16:38:50 +1 16:38:51 +1 16:38:52 +1 16:38:53 +1 16:39:01 +1 16:39:15 +1 16:39:34 jsmith: ? 16:39:37 +1 16:39:40 #agreed - FESCO adavises that Odoo not be listed as a Change, but the maintainer is free to add Odoo to the repositories (+1: 7, +0: 0, -1: 0) 16:39:43 (Sorry, having network issues at the moment) 16:39:47 jsmith: :( 16:40:05 and now for posterity/clarity 16:40:05 Proposal: Approve the PHP 7.1 self contained changed 16:40:16 +1 16:40:23 +1 16:40:33 +1 16:41:00 +1 16:41:03 +1 16:41:21 +1 16:41:39 dgilmore: ? 16:44:03 meh, we have the votes 16:44:10 #agreed - Approve the PHP 7.1 self contained Change (+1: 6, +0: 0, -1: 0) 16:44:18 #topic Next week's chair 16:44:39 who's up next week? 16:44:41 I will not be here next week. Will try and vote in tickets if I can... 16:44:51 doubtful i will be here 16:45:11 * paragan also will not be here for next week 16:45:18 could maybe cancel it next week then? 16:45:31 i will be at LPC the week after as well 16:45:37 which is unfortunate, but unavoidable 16:46:23 I'll not be here on Friday Nov 4th (Friday after next) but will be around next week 16:47:36 I will also not be here on Nov 4th, as I will be attending FUDCon APAC 16:47:40 so we're -2 members for next week, we should still have enough folks to host a meeting unless others are going to be gone that I'm not aware of 16:48:37 I'll take it if no one else is willing 16:48:56 I can take it 16:49:10 /me defers to jsmith 16:49:14 I'll be at All Things Open in Raleigh, but would be happy to still join and run the meeting 16:49:42 #info jsmith to chair 2016-10-28 16:49:49 #topic Open Floor 16:52:23 I'll give it another couple minutes and we'll wrap up 16:53:03 * dgilmore has nothing, sorry got distracted trying to finalise a patch 16:53:31 dgilmore: no worries, we had enough folks present to have the votes for a decision 16:53:49 I had said earlier i was +1 :) 16:54:01 ah 16:54:08 alright, let's call it 16:54:11 have a good one all! 16:54:12 #endmeeting