16:00:16 <jforbes> #startmeeting FESCO (2017-04-21)
16:00:26 <jforbes> #meetingname fesco
16:00:36 <jforbes> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:45 <jforbes> #topic init process
16:00:47 <sgallagh> .hello sgallagh
16:01:23 <nirik> morning
16:04:01 <dgilmore> hola
16:04:47 <jforbes> jwb jsmith?  I know Rathann said he was out
16:05:00 <jwb> sorry, here
16:05:39 <jforbes> Okay, that's quorum
16:05:54 <jforbes> #1653 Better communicating roles and responsibilities of FESCo
16:06:05 <jforbes> .fesco 1653
16:06:09 <nirik> and luckily pagure is up. ;)
16:06:14 <jforbes> https://pagure.io/fesco/issue/1653
16:06:18 <jforbes> Indeed.
16:06:42 <jforbes> So this is the follow up with nirik's statement in there. We have had some feedback, but not much.  Not sure if there is anything to do here, but it was still tagged meeting
16:06:43 <nirik> I tossed up a draft a while back.
16:07:49 <jforbes> I think the draft is well written, though sgallagh's suggestion would be helpful
16:08:04 <sgallagh> jforbes:  +1
16:08:07 <dgilmore> nirik: one query
16:08:10 <dgilmore> nirik: Approval and coordination of "changes" for traditional Fedora releases.
16:08:17 <dgilmore> why is traditional in there?
16:08:50 <nirik> dunno... I guess they apply to any releases... unless we get to a point where say a modular release doesn't have any new changes in it.
16:08:59 <nirik> happy to stike that word
16:09:15 <dgilmore> at a literal sense I could say I want to go off and do something not close to traditional so I do not need to bother about working with FESCO
16:09:33 <dgilmore> I would like traditional removed
16:09:43 <nirik> sure
16:09:46 <sgallagh> Seems reasonable to me
16:09:54 <jforbes> Seems a rather pedantic interpretation, but I could go with that
16:10:17 <jforbes> So do we want to do a quick edit in the ticket and vote on it?
16:10:26 <dgilmore> jforbes: I may spend too much of my time having to be pedantic
16:10:31 <dgilmore> sure
16:10:42 <jforbes> dgilmore: understandable.
16:11:05 <nirik> want me to add a comment with the change?
16:11:05 <jwb> i think we can likely just vote with the understanding that "traditional" will get axed
16:11:10 <nirik> yeah.
16:11:19 <dgilmore> I am good with that
16:11:25 <nirik> +1 with dgilmore and sgallagh's changes
16:11:46 <dgilmore> +1 with both changes
16:11:50 <sgallagh> +1 with both
16:12:16 <maxamillion> .hello maxamillion
16:12:18 <maxamillion> sorry I'm later
16:12:21 <maxamillion> late*
16:12:27 <dgilmore> hi later ;)
16:12:33 <maxamillion> :P
16:12:44 <jforbes> Okay, I have added a comment in the ticket to address both changes.
16:12:59 <jwb> +1
16:13:10 <maxamillion> I don't see a topic change ... which ticket?
16:13:21 <dgilmore> https://pagure.io/fesco/issue/1653
16:13:33 <dgilmore> maxamillion: zod bot is down
16:13:34 <jforbes> maxamillion: sorry, our bot is gone
16:13:36 <sgallagh> maxamillion: zodbot is down due to the ongoing network issues
16:13:37 <maxamillion> oh right
16:13:40 <maxamillion> thanks
16:14:10 <maxamillion> this wouldn't be a problem if I could be a decent adult and show up to things on time ;)
16:14:55 <jforbes> proposal: The updated statement in comments will be added to the FESCo wiki page
16:15:01 <dgilmore> +1
16:15:02 <jforbes> +1
16:15:07 <maxamillion> +1
16:15:22 <sgallagh> +1
16:15:46 <nirik> +1
16:17:02 <dgilmore> 5 is enough right?
16:17:06 <jforbes> #agreed The updated statement in comments will be added to the FESCo wiki page (+5,0,-0)
16:17:12 <jwb> i voted +1 above
16:17:23 <jforbes> #undo
16:17:27 <jforbes> #agreed The updated statement in comments will be added to the FESCo wiki page (+6,0,-0)
16:17:46 <jforbes> #topic #1695 F27 System Wide Change: Switch libidn-using applications to IDNA2008
16:18:02 <jforbes> .fesco 1695
16:18:12 <jforbes> https://pagure.io/fesco/issue/1695
16:18:37 <nirik> +1 from me.
16:18:49 <dgilmore> +1
16:18:50 <sgallagh> Might be a little rocky, but it necessary. +1
16:19:14 <jforbes> +1 here as well
16:19:32 <maxamillion> +1
16:20:21 <jforbes> jwb?
16:20:35 <jwb> +1 i guess
16:20:55 <jforbes> #agreed  F27 System Wide Change: Switch libidn-using applications to IDNA2008 is approved (+6,0,-0)
16:21:12 <jforbes> #topic #1697 F27 System Wide Change: Switch libcurl back to OpenSSL
16:21:33 <jforbes> .fesco 1697
16:21:41 <jforbes> https://pagure.io/fesco/issue/1697
16:21:52 <nirik> +1
16:22:15 <dgilmore> +1
16:22:27 <maxamillion> +1
16:22:55 <jforbes> +1
16:22:56 <sgallagh> +1
16:23:26 <jwb> +!
16:23:28 <jwb> er, +1
16:23:41 <jforbes> #agreed F27 System Wide Change: Switch libcurl back to OpenSSL is approved (+6,0,-0)
16:23:59 <jforbes> #topic #1698 systemd preset decision: thermald.service
16:24:15 <jforbes> .fesco 1698
16:24:26 <jforbes> https://pagure.io/fesco/issue/1698
16:25:11 <nirik> +1 to sgallagh's guideline addition.
16:25:21 <dgilmore> i am going to defer to jforbes on this
16:25:37 <maxamillion> I'm +1 to sgallagh's guideline addition as well
16:25:38 <nirik> this seems like a bad thing to enable by default...
16:25:50 <jwb> can we discuss the guideline part first?
16:25:52 <jforbes> Right, so there are 2 issues here. Let's vote on the guideline addition first.
16:26:00 <dgilmore> as to the change in guidelines, it seems fine
16:26:09 <sgallagh> Agreed. I am (obviously) +1 to the guideline change
16:26:13 <maxamillion> as far as the thermald.service, I'd defer that to the recommendation of the kernel team (jforbes, labbott, et al)
16:26:30 <dgilmore> guideline +1
16:27:22 <jforbes> so proposal from the ticket for prosperity: Append the Default Services criteria with "Installation of the package providing the unit auto-started by this preset may not change the behavior of any other service running on the system. Exceptions may be granted by FESCo on a case-by-case basis."
16:27:31 <jforbes> I am +1 there
16:28:11 <maxamillion> +1
16:28:26 <sgallagh> +1
16:28:35 <jforbes> jwb?
16:30:14 <jwb> +1
16:30:25 <jforbes> #agreed Append the Default Services criteria with "Installation of the package providing the unit auto-started by this preset may not change the behavior of any other service running on the system. Exceptions may be granted by FESCo on a case-by-case basis." (+6,0,-0)
16:30:28 <jwb> sorry, pulling double meeting duty :\
16:30:34 <sgallagh> #action sgallagh to draft the guideline change and add this to the Bugzilla template
16:30:47 <jforbes> So the next part is on the thermald service itself
16:31:22 <jforbes> Personally I think thermald is very good on most modern systems.  Unfortunately the Fedora userbase is not made up entirely of modern systems.
16:31:29 <sgallagh> As for the service, I'm generally opposed to enabling it by default, but if the kernel folks think it should be enabled, I can be swayed.
16:31:46 <nirik> jforbes: isn't it just papering over bugs in the kernel that should be fixed there?
16:31:59 <jforbes> I am against enabling by default
16:32:04 <dgilmore> jforbes: has anyone proposed adding it by default?
16:32:12 <nirik> I mean it may be easier to tweak and help some people, but no telling if it breaks others... and then if it doesn't run...
16:32:18 <jforbes> nirik: potentially in some areas
16:32:19 <nirik> dgilmore: yes
16:32:42 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=1440479 requests it be added as default on in presets
16:32:54 <dgilmore> nirik: thats not what I asked
16:33:04 <nirik> then can you expand?
16:33:18 <dgilmore> nirik: I mean adding to @core or some other comps group where the package would be installed by default
16:33:40 <dgilmore> as opposed to a user having to do "yum install thermald"
16:33:48 <sgallagh> No, that has not been requested as far as I know
16:34:11 <nirik> not yet that I know of either.
16:34:16 <nirik> but it easily could be
16:34:23 <dgilmore> jforbes: what part of enabling by default are you against?
16:34:30 <dgilmore> being installed on all systems?
16:34:39 <dgilmore> or having it run by default when installed?>
16:35:21 <dgilmore> I realise it would get tricky if we wanted to make sure it was disabled if in @core and all installs.
16:35:38 <dgilmore> I am guessing the expectation from people installing it would be that it runs
16:35:41 <nirik> well, if someone wanted to dnf install it, they would likely easily be able to enable it then... just like many other services
16:35:52 <dgilmore> sure
16:35:59 <jforbes> dgilmore: That is a valid point. I suppose if a user specifically requests it, having it default on wouldn't be so bad.  Though what happens when it gets brought into the default install for workstation or similar?
16:36:00 <dgilmore> but that may be unexpected
16:36:26 <dgilmore> jforbes: its a rock and a hard place
16:36:33 <sgallagh> What also happens if some other package pulls it in?
16:37:05 <jforbes> dgilmore: I don't really think it is. There are plenty of services that people can install and then have to enable
16:37:19 <dgilmore> jforbes: right
16:37:37 <dgilmore> which in cases of having to configure is expected
16:38:21 <dgilmore> in the end I am going to defer to what jforbes thinks is best, he is the expert. I just want to make sure we cover the bases in the discussion
16:39:23 <dgilmore> I think in the case of someone having to manually install the package enabled by default is fine. but if everyone gets it by default and some % of cases it hurts things, we should disable by default
16:39:40 <jforbes> dgilmore: If we could ensure that the package would never end up as a part of a default package set, I would be fine with enabled by default.
16:39:58 <dgilmore> jforbes: which we can not do
16:40:15 <dgilmore> we would have to have something to trigger a big fat warning if it happened
16:40:57 <dgilmore> so i think erring on the side of caution means we do not alllow the service to be enabled by default
16:41:56 <jforbes> The biggest problem is, while it works for a lot of users outside of the box, but for those it doesn't, it is going to be more subtle, and they may not notice, they may just notice a performance problem and assume Fedora sucks, or things might become more difficult to debug
16:42:31 <jforbes> I think the best course here is to be cautious.
16:43:04 <jforbes> proposal: thermald.service should not be enabled by default
16:43:09 <nirik> +1
16:43:10 <jforbes> +1
16:43:24 <sgallagh> +1
16:43:30 <dgilmore> +1
16:44:23 <jforbes> also of note, my use of commas in stream of consciousness writing sucks...
16:44:30 <jforbes> jwb maxamillion ?
16:44:36 <dgilmore> maxamillion: jwb: ^
16:44:43 <jwb> i defer to jforbes
16:44:53 <dgilmore> so +1?
16:45:01 <jwb> sorry guys, i'm really going to have to drop.  too many meetings right now
16:45:11 <jwb> i think i've logged my vote in most of the rest of the tickets
16:45:12 <maxamillion> +1
16:45:13 <maxamillion> sorry
16:45:22 <maxamillion> I can't multi-task to save my life today :/
16:45:23 <dgilmore> jwb: cool, thanks
16:45:30 <jforbes> #agreed thermald.service should not be enabled by default (+6,0,-0)
16:45:46 <jforbes> thanks jwb
16:45:51 <jforbes> #topic #1699 meeting: xml-security-c new maintainer request
16:46:06 <jforbes> .fesco 1699
16:46:14 <jforbes> https://pagure.io/fesco/issue/1699
16:46:55 <dgilmore> I guess the request here is to grant the permission request in pkgdb?
16:47:14 <dgilmore> some links in the issue wuld have been nice
16:47:28 <jforbes> Yeah, there is not a lot to go on here
16:47:34 <nirik> well, and perhaps orphan the other packages from that maintainer
16:47:52 <nirik> but yeah, the poor unresponsive maintainer process wasn't fully followed again. :(
16:47:56 <dgilmore> I see the request on Feb 20 for volunteers
16:48:44 <dgilmore> its kinda hard to see all with phx2 down
16:48:52 <nirik> Yeah.
16:49:02 <maxamillion> :/
16:49:12 <nirik> I'd probibly be ok with orphaning that maintainers packages, but not sure how many or if they were active in others.
16:49:36 <dgilmore> maybe we sohould ask for more info on the request
16:49:55 <dgilmore> I'm looking volunteers for maintaining xml-security-c package in Fedora. Current version is old in our repos and for example esteid (Estonian ID card) packages depend on newer xml-security-c (with openssl 1.1 support). I've already contacted anttix who is current package administrator to give committer rights to bruno and also contacted bruno to find out if he is still interested in maintaining it. Negative. And I'm also not too confident of mai
16:50:02 <dgilmore> So I'm seeking towards devel list to find out, are there any volunteers with enough courage to update and maintain it.
16:50:05 <dgilmore> thats the body of the request
16:50:15 <nirik> They are POC on 4 packages, co-maintainer on about 6 more
16:50:55 <dgilmore> seems like a poorly done non responsive maintainer request
16:50:55 <jforbes> Right, there is more to the thread. "Anttix, the initial maintainer of this package, has responded to my e-mail once. Have you contacted him directly?" which was unanswered
16:51:49 <jforbes> It was also pointed out in the thread that the non-responsive maintainer policy be initiated, with a link to the policy
16:52:06 <jforbes> That was Mar 30
16:52:27 <dgilmore> so I guess we push back and ask policy to be followed?
16:52:48 <nirik> well, the maintainer really may be unersponsive.
16:52:57 <jforbes> I would say so.  Unfortunately I can't use pkgdb to actually see the current status
16:52:59 <nirik> I can't tell if there's unanswered bugs for example. ;(
16:53:21 <dgilmore> hard to do anything right now
16:53:26 <maxamillion> should this be tabled until things are back online and we can gather all the info?
16:53:35 <jforbes> Okay, defer seems to make the most sense
16:53:40 <nirik> yeah, defer is fine.
16:53:54 <maxamillion> +1
16:54:04 <sgallagh> +1 to defer
16:54:21 <jforbes> #agreed xml-security-c new maintainer request is deferred until things are online and we have more insight.
16:54:35 <jforbes> #topic #1700 Lulzbot 3d printer firmware
16:54:49 <jforbes> .fesco 1700
16:54:57 <jforbes> https://pagure.io/fesco/issue/1700
16:55:22 <dgilmore> I think I am okay with shipping the prebuilt firmware while the issues are debugged.
16:55:37 <dgilmore> but I wonder if we should set a timelimit
16:55:50 <dgilmore> or allow it only in f25 and f26
16:56:02 <dgilmore> and ban from rawhide so it has to be fixed before f27
16:56:25 <nirik> that leaves rawhide users in a bit of a lerch.
16:56:33 <nirik> (not that there are likely too many affected)
16:57:03 <jforbes> I am curious as to the cause as well. I expect spot to chase it down. I am sure that he would get annoyed every time there is an update
16:57:24 <jforbes> Oh, hi spot!
16:57:57 <spot> jforbes: other half of the issue is that the upstream company is trying to hire someone to work on their firmware. :)
16:58:14 <spot> previous person left the company
16:58:16 <dgilmore> spot: is it just us using a newer compiler?
16:58:22 <spot> dgilmore: possibly.
16:58:37 <jforbes> I don't think that leaving it out of rawhide is a good idea, though I don't see a problem with making our approval conditional on a release lifespan
16:58:40 <spot> upstream just points to the older debian compiler and says "we dont have any issues"
17:00:08 <jforbes> So a temporary approval that would last through the F26 timeline, but require either local build or another request by F27 branch time?
17:00:29 <dgilmore> as it is exceptional, limiting its life seems wise. we can always extend if need be.
17:00:39 <sgallagh> jforbes: That sounds reasonable to me
17:00:50 <dgilmore> jforbes: that seems reasonable
17:01:21 <dgilmore> we can always extend if things have not been sorted but deny if its not been attempted
17:01:54 <maxamillion> +1 for limited exception that can be extended if necessary
17:01:59 <nirik> sure. +1
17:02:00 <jforbes> #proposal: packaging lulzbot prebuilt firmware along with source is acceptable though the F26 timeframe. If it cannot be built in Fedora by F27 branch time, an extension must be requested
17:02:14 <sgallagh> s/though/through/
17:02:20 <sgallagh> Otherwise, +1
17:02:29 <jforbes> #undo
17:02:34 <jforbes> #proposal: packaging lulzbot prebuilt firmware along with source is acceptable through the F26 timeframe. If it cannot be built in Fedora by F27 branch time, an extension must be requested
17:02:39 <jforbes> +1
17:02:48 <dgilmore> +1
17:03:14 <jforbes> #agreed packaging lulzbot prebuilt firmware along with source is acceptable through the F26 timeframe. If it cannot be built in Fedora by F27 branch time, an extension must be requested (+5,0,-0)
17:03:26 <jforbes> #topic Next week's chair
17:03:38 <jforbes> Any takers?
17:04:19 <sgallagh> I can probably cover it next week.
17:04:46 <maxamillion> I can take next week
17:04:55 <maxamillion> if sgallagh isn't able or doesn't want it :)
17:05:03 <jforbes> you guys want to fight it out? :)
17:05:07 <sgallagh> Be my guest.
17:05:23 <maxamillion> yeah, I'll do it ... I haven't chair'd in a while, probably my turn
17:05:46 <jforbes> #action maxamillion to chair next weeks meeting
17:05:56 <jforbes> #topic Open Floor
17:06:25 <dgilmore> nada aqui
17:06:46 <jforbes> If no one has anything, I will close out in 2 minutes
17:07:44 <sgallagh> I'm done
17:08:10 <jforbes> Of note, meeting minutes will be late. I am going to wait for infra to feed this through the bot to get a proper summary.  Laziness and all that
17:08:19 <maxamillion> jforbes: +1
17:08:42 <dgilmore> jforbes: cheers
17:08:49 <jforbes> #endmeeting