16:05:59 <jsmith> #startmeeting FESCO (2017-08-04)
16:05:59 <zodbot> Meeting started Fri Aug  4 16:05:59 2017 UTC.  The chair is jsmith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:59 <zodbot> The meeting name has been set to 'fesco_(2017-08-04)'
16:06:01 <jsmith> #meetingname fesco
16:06:01 <zodbot> The meeting name has been set to 'fesco'
16:06:03 <jsmith> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:06:03 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:06:05 <jsmith> #topic init process
16:06:09 <jsmith> .hello jsmith
16:06:10 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:06:12 <jforbes> .hello jforbes
16:06:13 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:06:20 <nirik> morning everyone
16:06:24 <nirik> .hello kevin
16:06:25 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:06:59 <dgilmore> g'day
16:07:09 <kalev> .hello kalev
16:07:10 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:07:50 <maxamillion> .hello maxamillion
16:07:51 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:08:12 <sgallagh> .hello sgallagh
16:08:13 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:08:55 <jsmith> Yay, we have a quorum, and lots of topics to discuss -- so let's get started
16:09:02 <maxamillion> +1
16:09:06 <jsmith> #topic Follow-ups
16:09:16 <jsmith> #topic #1736 - Don't automatically close security bugs on Fedora EOL
16:09:16 <jsmith> .fesco 1736
16:09:16 <jsmith> #link https://pagure.io/fesco/issue/1736
16:09:17 <zodbot> jsmith: Issue #1736: Don't automatically close security bugs on Fedora EOL - fesco - Pagure - https://pagure.io/fesco/issue/1736
16:09:49 <jsmith> Last week, we said we'd discuss on the list and come back -- there have been a couple of comments, but no major discussion
16:09:57 <nirik> so, I meant to add a comment to this... sgallagh's suggestion won't work
16:10:18 <nirik> (or at least currently)
16:10:56 <maxamillion> oh? I thought jkurik's comment suggests that it would
16:11:21 <nirik> we would need to create packagename-owner@fedoraproject.org accounts for every package (which we currently do not do)
16:11:41 <nirik> well, or would it work... perhaps I am misremembering how it tells
16:12:04 <jforbes> Why not the needinfo on the person it is assigned to?
16:12:26 <nirik> anyhow I think the needinfo is overkill... just move it to previous release at eol...
16:13:14 <kalev> let's do the Security keyword thing then so that it's possible to track the bugs properly?
16:13:38 <kalev> and it's easy enough to iterate over all security bugs later and add needinfo if we feel it's necessary to add later
16:14:08 <nirik> yeah, they should have the Security keyword already... we can use that
16:14:24 <Rathann> sorry guys, got sidetracked just before the meeting started
16:14:39 <kalev> ahh, even easier if they already have it
16:15:25 <kalev> Rathann: https://paste.fedoraproject.org/paste/3l4l5jc8P3pJ0jqEsc8lcg if you want to see scrollback
16:15:26 <maxamillion> +1 for security keyword
16:15:42 <nirik> proposal: eol scripts will be adjusted to move keyword: security bugs to the next release and add a note that this was a security bug and should be checked to see if it's fixed in the next release.
16:15:44 <Rathann> thanks kalev
16:15:55 <kalev> +1 to nirik's proposal
16:16:21 <jsmith> +1 to nirik's proposal
16:16:37 * nirik is +1 to his own
16:16:37 <jforbes> +1 nirik
16:17:10 <Rathann> +1
16:17:30 <Rathann> but I also like sgallagh's idea of setting needinfo to the pkg-owner
16:17:53 <sgallagh> +1
16:18:04 <maxamillion> +1
16:18:15 <sgallagh> Yeah, I wish we could needinfo everyone with commit privs. That way if the PoC is AWOL, someone else might see it.
16:18:31 <nirik> well, I can see how that would be anoying too tho
16:19:00 <nirik> say there's a security bug, but it's hard to fix... everytime a release EOL's you would needinfo again and the maintainer would have to clear it saying they are working on it and its not done yet
16:19:08 <jsmith> dgilmore: Voting?
16:19:58 <nb> I thought we used to have -owner aliases at one time
16:20:02 <nb> or am i imagining that
16:20:39 <jsmith> #agreed #1736 -  eol scripts will be adjusted to move keyword: security bugs to the next release and add a note that this was a security bug and should be checked to see if it's fixed in the next release
16:20:46 <jsmith> (+1:7,+0:0,-1:0)
16:21:08 <jsmith> In the interest of time, I'm going to move on to the next item.
16:21:09 <kalev> nb: that's only in the email system, not registered in bugzilla
16:21:09 <nirik> nb: we do, but bugzilla knows nothing about them... but I guess it would still work to cc them
16:21:17 <jsmith> #topic #1737 - Proposal: i686 SIG needs to be functional by F27 release date
16:21:17 <jsmith> .fesco 1737
16:21:17 <jsmith> #link https://pagure.io/fesco/issue/1737
16:21:18 <zodbot> jsmith: Issue #1737: Proposal: i686 SIG needs to be functional by F27 release date or we drop i686 kernel from F28 - fesco - Pagure - https://pagure.io/fesco/issue/1737
16:21:40 <jsmith> If I remember correctly, we lost quorum before we could take an action on this last week
16:21:49 <nirik> I kinda like mattdm's proposal here. Make the sig come up with critera... if they cannot do that then the answer is clear.
16:21:54 <kalev> mattdm came up with an idea with what I think makes most sense
16:21:56 * kalev nods.
16:22:22 <maxamillion> kalev: agreed
16:22:26 <maxamillion> nirik: +1
16:22:49 <nirik> I still see only 2 people listed on the page... and I am not sure Smooge was really interested or just wanted to help them organize.
16:22:56 <jsmith> Proposal: Give the SIG two weeks to come up with their criteria and come back to FESCo for approval
16:23:31 <kalev> +1 to jsmith's proposal
16:23:50 <sgallagh> jsmith: Are we assuming that if they cannot come up with criteria, we default to dropping i686 kernels?
16:24:05 <jsmith> sgallagh: I'm assuming so, yes.
16:24:11 <jforbes> For f28
16:24:12 <nirik> in f28 right?
16:24:15 <jsmith> For F28
16:24:25 <Rathann> +1 to jsmith's proposal with the above assumption
16:24:33 <nirik> +1 to the proposal (we should make sure we have someone post to the list about it tho to be very clear)
16:24:37 <jsmith> Proposal: Give the SIG two weeks to come up with their criteria and come back to FESCo for approval, and if they don't, drop i686 kernels for F28
16:24:47 <jforbes> +1 here
16:24:50 <maxamillion> +1
16:24:52 <Rathann> +1
16:25:17 <kalev> +1
16:25:46 <jsmith> sgallagh, dgilmore: Thoughts? Votes?
16:25:54 <nirik> still +1
16:26:00 <jsmith> nirik: Are you volunteering to post that, or would you like me to?
16:26:12 <dgilmore> sorry got distracted
16:26:14 <nirik> either way... I just want someone to.
16:26:59 <dgilmore> I am good either way as well
16:27:13 <dgilmore> if we drop it there is a bunch of other questions that come up
16:27:21 <jsmith> dgilmore: Can you elaborate?
16:27:41 <dgilmore> jsmith: well the only thing we could ship is a i386 Everything repo
16:27:55 <sgallagh> +1
16:27:56 <dgilmore> the only real use case for it would be multilib
16:28:02 <dgilmore> which I would like to go away
16:28:30 <dgilmore> so then the next question would be do we drop 32 bit x86 entirely
16:28:35 <sgallagh> dgilmore: I'd love to hear your thoughts (offline) on how we could get rid of multilib.
16:28:42 <sgallagh> I'm in favor :)
16:28:58 <dgilmore> sgallagh: easist way is drop i386
16:29:05 <dgilmore> then its gone
16:29:09 <nirik> sadly there's still people using it... for popular things even
16:29:16 <dgilmore> right
16:29:19 <sgallagh> dgilmore: Like I said, offline.
16:29:35 <kalev> I think it's a bit premature to drop i386 multilib right now
16:29:37 <jforbes> dgilmore: baby steps
16:29:59 <dgilmore> dropping the kernel will drop a ton of deliverables
16:30:04 <jsmith> dgilmore: Does that mean you're +1 for my proposal above, just to be clear?
16:30:13 <Rathann> dropping multilib would be a mistake at this point
16:30:18 <dgilmore> jsmith: i am 0
16:30:37 <Rathann> there's still tons of proprietary 32bit software that people want to run on Fedora
16:30:45 * kalev nods.
16:30:48 <dgilmore> jsmith: I am torn over the impact of it
16:30:51 <jsmith> #agreed #1737 - Give the SIG two weeks to come up with their criteria and come back to FESCo for approval, and if they don't, drop i686 kernels for F28 (+1:8,+0:0,-1:0)
16:30:59 <jsmith> dgilmore: Understood.
16:31:05 * nirik wonders if they could be flatpaked
16:31:14 <jsmith> #topic #1744 - F27 System Wide Change: NSS signtool deprecation
16:31:14 <jsmith> .fesco 1744
16:31:14 <jsmith> #link https://pagure.io/fesco/issue/1744
16:31:15 <jforbes> haha
16:31:15 <zodbot> jsmith: Issue #1744: F27 System Wide Change: NSS signtool deprecation - fesco - Pagure - https://pagure.io/fesco/issue/1744
16:31:21 <dgilmore> nirik: that needs a kernel
16:31:29 <Rathann> nirik: now that's an idea
16:31:30 <dgilmore> nirik: we need a kernel to make the base imag
16:31:32 <dgilmore> image
16:31:40 <nirik> ah well, anyhow...
16:32:05 <jsmith> Sorry to rush the conversation onto the next topic, but we've got a ton of things to cover today
16:32:08 <nirik> +1 here. I thought we did this one a while back...
16:32:21 <maxamillion> yeah, I thought we did as well
16:32:21 <maxamillion> +1
16:32:23 <kalev> +1
16:32:31 <jsmith> Apparently it was discussed on 7/21, but there wasn't quorum
16:32:35 <jsmith> +1 from me
16:32:49 <dgilmore> I am -1 as we are past systemwide change deadline
16:32:56 <jforbes> I am still +1
16:33:26 <dgilmore> 2017-07-04 Change Checkpoint: Proposal submission deadline (System Wide Changes)
16:33:43 <dgilmore> I am +1 for f28
16:33:55 <nirik> dgilmore: they submitted in time...
16:34:03 <nirik> 3 weeks ago
16:34:12 <dgilmore> nirik: tahts not in time
16:34:18 <nirik> oh, system wide. hum
16:34:36 <dgilmore> system wide was 4 weeks ago
16:34:48 <dgilmore> I am a big fat -1
16:34:55 <nirik> why is it systetm wide?
16:35:02 <dgilmore> sucks but we have to enforce the schedule
16:35:11 <maxamillion> dgilmore: yeah, that's a good point
16:35:21 <sgallagh> nirik: Because packages may be using it to sign things like jars
16:35:34 <sgallagh> Though the proposal owner was unaware of any in-Fedora uses
16:35:41 <jforbes> I didn't even consider the fact that it might be system wide
16:35:53 <sgallagh> I'm actually kind of inclined to recategorize it as self-contained.
16:36:02 <jsmith> So by my math, they missed the deadline by two days (but looking by the history of the wiki page, may have had the initial version a day before the deadline)
16:36:08 <sgallagh> This isn't really going to have any impact on the rest of the official Fedora repo
16:36:15 <jsmith> sgallagh: Leaning there myself, considering the scope
16:36:43 <Rathann> also it'll continue to be available for some time, just in a different path
16:36:46 <maxamillion> doesn't seem system wide
16:36:47 <nirik> yeah, I don't think it's really system wide... unless this tool is much more widespread than I think it is.
16:36:48 <sgallagh> Hmm, actually I'm rethinking.
16:36:49 <jsmith> Either way, I'm still +1 towards accepting it.  If they missed the deadline, it was only by a couple of days
16:36:58 <dgilmore> I guess we should get the impact reevaluated
16:37:15 <dgilmore> as a systemwide I am -1
16:37:16 <sgallagh> Even if it's self-contained, if it causes unforseen problems, we are already in a schedule crunch.
16:37:27 <sgallagh> (sorry, thinking through this as we go)
16:37:28 <maxamillion> if it is actually system wide, I'm going to -1 based on schedule as dgilmore points out
16:37:44 <sgallagh> I think I'm actually going to say -1 here as well.
16:37:53 <dgilmore> I am +1 to f28 and +1 if its really self contained
16:37:57 <sgallagh> It's not critical that this land for any reason I can see.
16:38:20 <sgallagh> So I'd push it to F28 and be done with it
16:38:24 * Rathann notes that there are alternative tools for the same already, at least the change says so
16:38:28 * nirik nods. I am +1 to f28 or +1 if they change it to self contained...
16:38:36 <jforbes> That seems to make the most sense
16:38:40 <sgallagh> To be clear, I think I'm -1 on self-contained as well
16:38:41 <dgilmore> proposal reject as a f27 systemwde change, accept as a f28 systemwide change
16:38:47 <maxamillion> nirik: +1
16:38:59 <jsmith> dgilmore: +1,  I guess
16:39:31 <nirik> sure I guess.
16:39:33 * Rathann is +1 either way
16:39:39 <dgilmore> unless everyone decides ist self contained
16:39:44 <kalev> sure, I can be +1 to that
16:39:49 <sgallagh> If we want to get F27 out at anything resembling "on time", I think we need to make hard decisions about any change that might introduce issues.
16:39:54 <Rathann> the impact is small in my opinion
16:40:17 <dgilmore> if nothing in the distro uses it the imact is small and its self contained
16:40:19 <nirik> I can't imagine this blocking us, but ok
16:40:37 <sgallagh> dgilmore: Nothing known to the reporter is using it. That may not be the same thing.
16:40:46 <sgallagh> s/reporter/proposer/
16:40:51 <dgilmore> sgallagh: sure
16:41:05 <dgilmore> which may only be found out after making the change
16:41:20 <jsmith> OK, keep me honest here with my counting... jsmith, nirik, Rathann, Kalev, and dgilmore are +1 to dgilmore's proposal.  I'm assuming jforbes and sgallagh are as well, but didn't see a clear vote from them.
16:41:22 <sgallagh> dgilmore: Right, and if that happens, I'd rather we did that in Rawhide post-branch
16:41:35 <dgilmore> sgallagh: sure
16:41:45 <sgallagh> jsmith: I am in favor of rejecting it from F27
16:41:46 <jsmith> Oh, how'd I miss maxamillion
16:41:55 <kalev> also, I still think it would make more sense to split this out to a subpackage to phase it out, it could be nss-tools-unsupported or something like that, and keep it in /usr/bin
16:41:57 <jforbes> I am +1, yes
16:42:01 <dgilmore> sgallagh: my proposal was accept if for f28
16:42:12 <sgallagh> Call me +1 for that, then
16:42:38 <maxamillion> +1 for me as well
16:42:56 <kalev> I don't really like how with the current approach with moving it to a subdir we'll a) have an unsupported tool in the default install
16:43:03 <kalev> and b) how we'll break end users scripts who might be using it
16:43:10 <dgilmore> jsmith: so my proposal passes , unless anyone else wants to propose something else
16:43:15 <jsmith> #agreed #1744 - Reject as an F27 system-wide change, and accept as an F28 system-wide change (+1:8:+0:0,-1:0)
16:43:17 <sgallagh> kalev: provide that as feedback after we reject it
16:43:27 <jsmith> #topic #1745 - F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
16:43:27 <jsmith> .fesco 1745
16:43:27 <jsmith> #link https://pagure.io/fesco/issue/1745
16:43:29 <zodbot> jsmith: Issue #1745: F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL - fesco - Pagure - https://pagure.io/fesco/issue/1745
16:43:34 <dgilmore> +1
16:43:34 <jforbes> kalev: they have a whole release cycle and a half to fix it
16:43:40 <dgilmore> gahh
16:43:41 <dgilmore> no
16:43:42 <sgallagh> So, I have good news about this one
16:43:42 <dgilmore> -1
16:43:45 <dgilmore> same reason
16:43:48 <dgilmore> systemwide
16:43:59 <jsmith> sgallagh: Oh?
16:44:03 <sgallagh> This is basically ready to go now.
16:44:40 <sgallagh> The only known Fedora packages that were holding us back were the FreeIPA stack
16:45:06 <sgallagh> But dgilmore makes a good point about it being really late for this.
16:45:15 <maxamillion> agreed
16:45:33 <maxamillion> -1 based on systemwide deadline
16:45:42 <dgilmore> I propose the same as the previous change
16:45:46 <jsmith> I'd also rather shift this to F28
16:45:58 <sgallagh> Yeah, I think at this point in the cycle I have to agree.
16:46:00 <jsmith> (more due ot the F27 time-crunch, rhan the deadline)
16:46:09 <sgallagh> jsmith: +1
16:46:14 <nirik> yeah, moving to f28 and providing a long ramp seems good.
16:46:22 * kalev nods.
16:46:29 <Rathann> agreed
16:46:30 <jsmith> Proposal: Defer this to F28
16:46:37 <dgilmore> proposal: Reject as an F27 system-wide change, and accept as an F28 system-wide change
16:46:40 <dgilmore> ack
16:46:44 <jforbes> +1 dgilmore
16:46:48 <sgallagh> Proposal: Due to the short F27 cycle, we request that this be deferred until F28 and landed as soon after branch as possible.
16:46:48 <Rathann> +1
16:46:57 <kalev> so many proposals :)
16:47:06 <jsmith> And they're all essentially the same.
16:47:16 <kalev> sgallagh's is perhaps the most informative?
16:47:16 <sgallagh> I'll amend mine, one sec
16:47:22 <jsmith> I think we'll go with sgallagh's as it's the most verbose
16:47:29 <dgilmore> +1
16:47:40 <sgallagh> Proposal: Due to the short F27 cycle, we defer this until F28 and accept if for that release. Please  land it as soon after branch as possible.
16:47:42 <jsmith> (as amended, perhaps, once he amends it)
16:47:50 <sgallagh> s/if/it/
16:47:52 <jsmith> Still +1 to that proposal
16:47:56 <sgallagh> +1
16:48:01 <Rathann> still +1
16:48:02 <kalev> +1
16:48:08 <dgilmore> +1
16:48:12 <jforbes> +1
16:48:13 <nirik> +1
16:48:15 <maxamillion> +1
16:48:43 <jsmith> #agreed #1745 -  Due to the short F27 cycle, we defer this until F28 and accept it  for that release. Please land it as soon after branch as possible. (+1:8,+0:0,-1:0)
16:48:57 <jsmith> #topic #1747 - F27 System Wide Change: RPM 4.14
16:48:58 <jsmith> .fesco 1747
16:48:58 <jsmith> #link https://pagure.io/fesco/issue/1747
16:49:00 <zodbot> jsmith: Issue #1747: F27 System Wide Change: RPM 4.14 - fesco - Pagure - https://pagure.io/fesco/issue/1747
16:49:13 <dgilmore> same :(
16:49:24 <dgilmore> though parts of it have already landed
16:49:35 <sgallagh> This was approved weeks ago
16:49:40 <sgallagh> What is the open question?
16:49:47 <maxamillion> sgallagh: how many weeks ago? :)
16:49:54 <jsmith> Oh, good call -- not sure why it was still o nthe list.  It was voted on in the 7/21 meeting.
16:49:55 * dgilmore thinks its sad we have so many system wide changes coming to us this late
16:50:00 <maxamillion> deadline was 4 weeks ago wasn't it?
16:50:05 <dgilmore> maxamillion: yes
16:50:07 <sgallagh> maxamillion: We voted to approve two weeks ago
16:50:10 <jsmith> dgilmore: Part of that is that we haven't had quorum for a couple of meetings.
16:50:16 <maxamillion> sgallagh: rgr
16:50:26 <maxamillion> we weren't paying attention to schedule ... we really need to do that
16:50:39 <jsmith> #agreed #1747 -- This was already approved on 2017-07-21
16:50:40 <dgilmore> maxamillion: indeed
16:50:49 <jsmith> #topic #1749 - F27 Self Contained Change: VirtualBox Guest Integration
16:50:49 <jsmith> .fesco 1749
16:50:49 <jsmith> #link https://pagure.io/fesco/issue/1749
16:50:50 <sgallagh> maxamillion: It was submitted four weeks ago and hit FESCo three weeks ago and we approved it two weeks ago
16:50:50 <zodbot> jsmith: Issue #1749: F27 Self Contained Change: VirtualBox Guest Integration - fesco - Pagure - https://pagure.io/fesco/issue/1749
16:50:51 <sgallagh> Seems in order
16:51:21 <sgallagh> I'm with jwb: I'd REALLY like this to land, but I don't want to see us carrying private patches for it.
16:51:22 <nirik> right, it was submitted before the deadline, but then needs a week discussion on list then needs us to meet... so there are a lot of delays in there.
16:51:27 <sgallagh> Didn't work really well with kdbus...
16:51:45 * nirik wants to hear jforbes's thoughts on this
16:51:51 <dgilmore> jforbes: what say you?
16:51:53 <jsmith> nirik: Me too :-)
16:52:21 <jforbes> Sorry, was going through the minutes from before where we had looked at some of this
16:52:25 <kalev> I'd really like to see this too
16:52:25 <jsmith> (That being said, I'm also inclined to defer and revisit the decision in the F28 timeframe)
16:52:47 <kalev> I think I heard the change author say somewhere that one of the guest drivers already made it to the staging tree
16:52:49 <sgallagh> jsmith: I suspect in that timeframe it will be upstream and a freebie
16:52:50 <jforbes> VirtualBox, here's the thing
16:53:04 * jsmith listens attentively
16:53:07 <jforbes> Yes, one guest driver is in staging (very low bar of entry there)
16:53:13 <kalev> but there's more than one driver and others still need to make it to staging
16:53:41 <jforbes> The rest of them are not.   I really do not have any inclination to carry them as a patch in hopes that they may eventually one day get upstream
16:54:17 <maxamillion> that doesn't give me the warm and fuzzies
16:54:32 <nirik> so defer until they are upstream?
16:54:32 <jsmith> Proposal: Reject for F27, revisit the decision later for F28
16:54:34 <jforbes> They have a history of saying "lets get vbox upstream", making a couple of posts ignoring feedback, and forgetting about it.  Long history, over 10 years
16:54:49 <Rathann> right, defer until the kernel patches are upstream
16:54:51 <kalev> how is this different from, let's say i686 sig where the sig promises to take care of one part of the kernel? if the feature owner promises to take care of the patch, is this in any way different?
16:54:56 <nirik> well, hans is driving it this time, and he knows the drill.
16:54:58 <sgallagh> Proposal: FESCo would prefer that Fedora does not carry these patches, instead defer until VirtualBox drivers are upstreamed into the kerne.
16:55:12 <maxamillion> jforbes: yeah, I seem to remember a lot of articles about vbox+lkml in the paste to that effect
16:55:22 <maxamillion> sgallagh: +1
16:55:23 <jsmith> +1 to sgallagh's proposal (or my own)
16:55:36 <Rathann> +1
16:55:43 <dgilmore> I know hans knows the right thing to do
16:55:45 <sgallagh> jsmith: I don't want to specifically refer to F28. That sort of sets a deadline.
16:55:47 <jforbes> We do not enable staging drivers as policy, but if hans is interested in maintaining them, we will be happy to enable the drivers as they hit staging
16:55:55 <dgilmore> and he has a history of getting changes in the mainline kernel
16:56:15 <sgallagh> jforbes: Interested enough to do this in the F27 cycle?
16:56:20 <jsmith> sgallagh: My intention was not to set a deadline -- just to kick the can down the road.  We can always re-evaluate for F28 and kick the can farther down the road.
16:56:44 <nirik> kalev: I would think i686 fixes would be very upstreamable... if they wanted to carry a big patch for adding the arch or something I could see the kernel maintainers not wanting to do that there too.
16:56:45 <sgallagh> jsmith: If we're doing this, I'd rather it be clear that we want this upstream.
16:56:55 <jforbes> sgallagh: Yes, and no.  If they land before F25 is EOL, it will get the drivers during a rebase.
16:57:00 <dgilmore> assumim jforbes is okay with hans maintaing things, i am +1 to f27
16:57:32 <kalev> I am +1 to F27 as well
16:57:33 <sgallagh> I thought this was further along than it is from this discussion.
16:58:02 <sgallagh> I'm -1 to F27.
16:58:07 <jforbes> We don't turn off drivers on rebases, but we do turn them on.
16:58:35 <jforbes> This isn't going to land by F27 GA, if they follow through, it may land as an update
16:58:39 <dgilmore> jforbes: so in theory we may get delayed some while hans does a rebase
16:58:50 <nirik> well, provided the change is updated to reflect things (ie, only once they are merged in staging, and on a kernel rebase will they be enabled) I'm +1 for whenever that happens.
16:58:55 <sgallagh> At which point it's realistically an F28 feature that happened to get backported.
16:58:58 <sgallagh> Not an F27 feature.
16:59:09 <jforbes> correct
16:59:21 <jsmith> I'm fine with that
16:59:23 <jforbes> dgilmore: the delay is waiting for them to get upstream
16:59:24 <sgallagh> So I'm happy to say -1 on F27. Don't put it in until after branch.
16:59:54 <kalev> I would be sad to see a hardware enablement feature not land if it's ready in time for F27
17:00:11 <jforbes> Well, they will get enabled as they are added upstream, regardless of schedule
17:00:23 <sgallagh> kalev: I would be sadder still to see F27 not land in time because of a half-baked hardware-enablement feature :)
17:00:57 <jsmith> OK, let's see how votes are shaping up around sgallagh's proposal
17:01:01 <sgallagh> Right, if it lands in whatever upstream kernel we ship for F27, that's all well and good and we can reverse this decision
17:01:13 <jforbes> Correct
17:02:00 <sgallagh> But as for carrying them privately, I don't like that idea and think it's unnecessary risk for F27
17:02:25 <sgallagh> Another bus will be along soon
17:02:42 <maxamillion> sgallagh: +1
17:03:01 <jsmith> Amended proposal: FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until after branch or until upstreamed.
17:03:03 <jsmith> Thoughts?
17:03:18 <dgilmore> +1
17:03:19 <sgallagh> jsmith: +1
17:03:25 <Rathann> +1
17:03:30 <kalev> +1
17:03:49 <jforbes> -1 to that proposal, it implies that we will accept the patches after branch
17:03:50 <Rathann> actually s/until after branch or//
17:04:06 <Rathann> so, just like jforbes said
17:04:31 <sgallagh> That's fair.
17:04:31 <jsmith> jforbes: Well, I thought we would *if* Hans is willing to do all the maintenance work -- maybe that was a bad assumption on my part
17:04:36 <maxamillion> ah yeah, fair point
17:04:52 <maxamillion> I don't think we should accept until it's upstream
17:05:05 <nirik> proposal: accept change with the proviso that patches are all ustreamed and would be enabled in a rebase. If that rebase takes place after f27 release, make this a f28 change
17:05:06 <maxamillion> adding more work to the kernel team is bad form
17:05:08 <sgallagh> Amended proposal: FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until  upstreamed. Private patches may be considered for a F28 Change if they are sufficiently ready for testing.
17:05:09 <jforbes> I am absolutely not against having vbox support in the kernel, I am however very much against carrying patches that may never land upstream
17:05:15 <dgilmore> jforbes: i read it as being possibly accepter to rawhide after branching
17:05:17 <maxamillion> nirik: +1
17:05:22 <maxamillion> sgallagh: +1
17:05:26 <dgilmore> gahh
17:05:28 <maxamillion> either nirik or sgallagh's proposal
17:05:37 <dgilmore> type failure here
17:05:55 <jsmith> I'm +1 to either of those new proposals
17:06:13 <jforbes> +1 sgallagh We may revisit the status in F28, if there is a clear path.
17:06:17 <Rathann> +1
17:06:50 <dgilmore> what jforbes said
17:07:16 <sgallagh> jforbes: I was trying to communicate that. Feel free to suggest a clearer wording.
17:07:17 <nirik> seems a bit contradictory, but sure... "deferring until upstreamed" "private patches may be accepted"
17:07:44 <jforbes> sgallagh: I think your wording is fine there
17:07:44 <jsmith> Let's spend two more minutes cleaning up the language a bit, shall we?
17:08:36 <jforbes> nirik: It makes sense to me because if it gets upstreamed, F27 will get it on rebase.
17:08:46 <dgilmore> instead deferring until it is clear that there is a clear path they will be accepted upstream
17:09:08 <sgallagh> Reworded: FESCo would prefer that Fedora doesn't carry private  patches for F27 release kernel.If the patches are upstreamed, we will accept them in a rebase. Private patches may be considered for a F28 Change if they are sufficiently ready for testing.
17:09:18 <nirik> jforbes: sure, but then what private patches are there for f28?
17:09:44 <sgallagh> nirik: The private patches bit is in case they're not upstream but *are* ready for prime-time
17:09:48 * nirik 's uderstanding is that you don't want to carry any private patches
17:10:03 <dgilmore> Amended proposal: FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until it is clear that there is a clear path they will be accepted upstream.
17:10:20 <sgallagh> I guess we  could drop the F28+ part entirely and leave it up to the next FESCo to figure out
17:10:30 <nirik> dgilmore: +1
17:10:36 <jforbes> nirik: In general we don't, but if it were to land in say next, meaning there is a very clear path upstream, it would just be after the F28 release kernel, we may carry them
17:10:39 <sgallagh> dgilmore: +1  I can work with that
17:10:51 <nirik> ok
17:11:15 <jsmith> Everybody OK with dgilmore's latest language then?
17:11:23 <nirik> I guess it depends on what 'upstream' means really... acked, landed in next, landed in staging, landed in normal drivers, etc.
17:11:24 <maxamillion> I am if jforbes is
17:11:25 <kalev> sounds good to me
17:11:25 <jforbes> I am fine with carrying a patch when there is a guarantee that it goes away in a release or 2
17:11:52 <kalev> yep, I too think it may make sense to _backport_ the patch if needed
17:11:56 <jforbes> nirik: We will accept staging for this
17:12:04 <kalev> anyway, +1 to dgilmore's proposal
17:12:05 <dgilmore> nirik: thats up to jforbes and Laura to decide
17:12:12 <jforbes> I am +1 to dgilmore's proposal
17:12:13 * nirik nods. right. +1
17:12:21 <Rathann> +1
17:12:22 <jsmith> I'm +1 to dgilmore's proposal
17:12:35 <maxamillion> +1 to dgilmore's proposal
17:13:40 <dgilmore> i am +1 obviously
17:13:53 <jsmith> #agreed #1749 - FESCo would prefer that Fedora doesn't carry these patches for F27 release kernel, instead deferring until it is clear that there is a clear path they will be accepted upstream. (+1:8,+0:0,-1:0)
17:14:06 <jsmith> #topic #1750 - Decide if EOL is one month after release, four weeks, or something else
17:14:06 <jsmith> .fesco 1750
17:14:06 <jsmith> #link https://pagure.io/fesco/issue/1750
17:14:07 <zodbot> jsmith: Issue #1750: Decide if EOL is one month after release, four weeks, or something else - fesco - Pagure - https://pagure.io/fesco/issue/1750
17:14:31 <kalev> mattdm suggested 5 weeks, I think
17:14:40 <dgilmore> kalev: he did
17:14:42 <nirik> so I thought (but couldn't find) that we delegated this to releng a while back...
17:14:53 * dgilmore would rather not push updates for a week longer
17:15:04 <nirik> ie, fesco used to decide dates, then just decided to let releng do it when it was good for them.
17:15:15 <jsmith> nirik: I'm fine with that :-)
17:15:16 <dgilmore> I do wish I knew what the probelem with the exitisting setup is
17:15:26 <dgilmore> it was always ~1 month
17:15:26 <maxamillion> dgilmore: same
17:15:37 <dgilmore> we defaulted to that being 4 weeks years ago
17:15:55 <dgilmore> a difference of 2-3 days
17:16:03 <sgallagh> I don't really think he cares as long as we document it accurately.
17:16:20 <sgallagh> If it's 28 days, then let's just print that and move on
17:16:21 <nirik> its one month in one place and 4 weeks in another apparently
17:16:21 <jsmith> sgallagh: Agreed
17:16:47 <maxamillion> nirik: ah ok, so there's an inconsistency in the information provided
17:16:51 <maxamillion> that's fair
17:17:12 <dgilmore> does it say 1 month or approximately 1 month
17:17:15 <dgilmore> ?
17:17:19 <kalev> I think mattdm's idea was that in marketing, it's easier to say one month, and in reality make sure that we actually do that a few more days than that so that nobody feels cheated
17:17:27 <kalev> so 5 weeks
17:17:51 <jsmith> Proposal: Declare the time as "35 days"
17:17:55 <nirik> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Schedule_Methodology
17:18:03 <nirik> "One release plus one month"
17:19:17 <sgallagh> jsmith: I propose that FESCo declares that all months are 30 days long. Extra days at the end of the calendar year are discarded. :)
17:19:40 <nb> :)
17:19:41 <nirik> ha
17:19:42 <jsmith> -1 to sgallagh's proposal
17:19:44 <puiterwijk> How about lunar months at the time of release?
17:20:17 * sgallagh notes that he was attempting to use satire to call attention to the ridiculousness of this debate
17:20:55 <jsmith> sgallagh: https://en.wikipedia.org/wiki/International_Fixed_Calendar
17:20:56 <sgallagh> IMHO, the use of "month" for marketing purposes is unnecessary. Let's say "four weeks" or "28 days" everywhere and have done. <-- Proposal
17:21:05 <nirik> how about just making it 4 weeks.
17:21:08 <nirik> +1
17:21:08 <jsmith> sgallagh: +1
17:21:30 <Rathann> +1
17:21:53 <sgallagh> +1, to be clear
17:21:55 <maxamillion> +1
17:21:59 <kalev> +1
17:22:04 <dgilmore> +1
17:22:22 <mattdm> four weeks sounds a lot scarier to me than one month
17:22:32 <sgallagh> As an aside, this meeting is starting to feel like "28 Days Later"...
17:22:32 <mattdm> but I'm fifty-fifty on whether that's a bad thing :)
17:22:35 <sgallagh> mattdm: GOOD
17:22:47 <sgallagh> The whole point of EOL is to scare people off the thing we don't want to support anymore
17:22:47 <jsmith> mattdm: You'll note my first proposal was "35 days", but nobody liked that at all...
17:22:53 <dgilmore> mattdm: in most people mind 4 weeks is a month
17:23:08 <maxamillion> ¯\_(ツ)_/¯
17:23:11 <jsmith> jforbes: Vote?
17:23:17 <jforbes> +1
17:23:19 <mattdm> too many geeks involved here for that kind of imprecision to fly :)
17:23:53 <dgilmore> a month rounded to the closest Tuesday ;)
17:24:01 <jsmith> #agreed $1750 -  The use of "month" for marketing purposes is unnecessary. Let's say "four weeks" or "28 days" everywhere and have it done (+1:8,+0:0,-1:0)
17:24:03 <kalev> I think mattdm is in the best position to say which of these options works best in reality, so I'm willing to get behind with what he says :)
17:24:10 <jsmith> #topic New business
17:24:24 <jsmith> #topic #1751 - Request to accept a Self Contained Change after deadline
17:24:24 <jsmith> .fesco 1751
17:24:24 <jsmith> #link https://pagure.io/fesco/issue/1751
17:24:25 <zodbot> jsmith: Issue #1751: Request to accept a Self Contained Change after deadline - fesco - Pagure - https://pagure.io/fesco/issue/1751
17:24:32 <jsmith> I spoke to pbrobinson about this one the other day
17:24:42 <jsmith> Seems like the work is essentially done, and the ticket was really just opened for marketing purposes
17:24:52 <pbrobinson> yes, correct
17:24:56 <jsmith> So I'm strongly inclined to vote +1 for it
17:25:01 <maxamillion> yeah, +1 here
17:25:12 <jforbes> +1
17:25:14 <pbrobinson> there's a little testing and some new versions of u-boot but that's normal release cycle stuff
17:25:19 <maxamillion> self contained and the work is done? I'm in :)
17:25:21 <nirik> sure. +1
17:25:22 <sgallagh> Yeah, +1
17:25:23 <kalev> +1
17:25:35 <Rathann> +1
17:25:55 <dgilmore> +1
17:26:11 <jsmith> #agreed #1751 Change is accepted (+1:8,+0:0,-1:0)
17:26:22 <jsmith> #topic #1690 - F27 Self Contained Changes
17:26:22 <jsmith> .fesco 1690
17:26:22 <jsmith> #link https://pagure.io/fesco/issue/1690
17:26:25 <zodbot> jsmith: Issue #1690: F27 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1690
17:26:27 <jsmith> And we have a bunch of these...
17:26:35 <jsmith> #topic Unified database for DNF
17:26:35 <jsmith> #link https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF
17:26:54 <jsmith> I'm +1 for this one
17:27:12 <sgallagh> ignatenkobrain: Are you around? What's the status of this?
17:27:21 <sgallagh> Is it just waiting for the go-ahead to land, or is there work still to be done?
17:27:33 <jsmith> The wiki page says the patches are there
17:28:02 <sgallagh> What about the PackageKit side?
17:28:08 <nirik> +1 but yeah...
17:28:16 <sgallagh> I'm kind of wary of calling this self-contained.
17:28:23 <maxamillion> sgallagh: agreed
17:28:34 <maxamillion> I was just about to ask if it's truly considered self contained
17:28:35 <jsmith> sgallagh: The more I read this, the more I tend to agree with you.
17:28:52 <jsmith> Proposal: Defer to F28, and re-evaluate if it's really self-contained
17:28:59 <sgallagh> I'm leaning slightly on the -1 side right now. I'm hoping ignatenkobrain can alleviate my fears.
17:29:09 <ignatenkobrain> sorry for delay
17:29:10 <ignatenkobrain> I'm here
17:29:14 <maxamillion> ignatenkobrain: o/
17:29:30 <ignatenkobrain> sgallagh: SWDB still WIP, though
17:29:35 <sgallagh> Because any change to low-level plumbing during this short cycle has me on edge.
17:30:02 <ignatenkobrain> chang is definitely self-contained
17:30:17 <sgallagh> ignatenkobrain: Except the part where multiple package management tools need to integrate with it.
17:30:22 <ignatenkobrain> not really
17:30:36 <ignatenkobrain> only dnf uses yumdb
17:30:45 <maxamillion> does packagekit not?
17:30:51 <ignatenkobrain> no, it has its own DB
17:30:58 <maxamillion> of course it does :)
17:31:17 <jforbes> nice
17:31:22 <sgallagh> ignatenkobrain: The Change implies that the purpose is to move PK onto swdb as well
17:31:25 <ignatenkobrain> if something else uses ymudb, let me know and I will write blogpost asking people to not use that software ;)
17:31:38 <ignatenkobrain> yes, edynox has patches to integrate PK with swdb
17:31:44 <ignatenkobrain> through libdnf
17:32:00 <ignatenkobrain> what's the current status of -1/0/+1?
17:32:18 <ignatenkobrain> I mean if I should start arguing for inclusion it into F27 or just agree for moving to F28?
17:32:42 <maxamillion> ignatenkobrain: there was concern about it having a lager impact than we originally understood, but it sounds (at least as I understand it) that it's not a wide spanning impact
17:32:57 <nirik> well, how much more work is pending? we have a very tight schedule this cycle. ;(
17:33:06 <maxamillion> ignatenkobrain: also what nirik said
17:33:10 <Rathann> what happens if PK is not ported to the new swdb?
17:33:18 <sgallagh> Yeah, if it's not ready to happen basically today, I'm concerned about inclusion at this point.
17:33:21 <ignatenkobrain> Rathann: it still uses its own db
17:33:21 <Rathann> I mean not ported in time?
17:33:44 <ignatenkobrain> nirik: everything is pretty much done, needs cleanup and testing
17:34:33 <Rathann> do we end up with things like needing to manually mark installed packages with "dnf mark" or dnf will happily remove them by default?
17:34:43 <nirik> well, the big advantage here is both of them using the same db... if they aren't then it's not so interesting.
17:34:55 <nirik> Rathann: you mean like it is today? ;)
17:35:24 <ignatenkobrain> when dnf finds that swdb doesn't exist but yumdb does, it will automatically convert db
17:35:26 <ignatenkobrain> though it can't do opposite
17:35:49 <Rathann> nirik: I mean https://fedoraproject.org/wiki/Common_F24_bugs#DNF_might_remove_essential_system_packages_if_you_used_PackageKit_.28GNOME_Software.2C_KDE_Apper.29_in_the_past
17:36:00 <Rathann> is this still a thing today?
17:36:08 <nirik> yes, as far as I know
17:36:12 <Rathann> oh
17:36:15 <ignatenkobrain> not really
17:36:27 <kalev> ignatenkobrain: can you make sure that when it goes through PK, the yumdb -> swdb conversion also automatically happens?
17:36:44 <ignatenkobrain> kalev: sure
17:36:52 <kalev> great
17:36:59 <nirik> oh I guess it was fixed.
17:37:35 <ignatenkobrain> btw, when is the deadline?
17:37:36 <kalev> Rathann: I fixed that a few releases ago
17:37:48 <ignatenkobrain> for self contained changes to be complete
17:38:29 <nirik> 2017-09-05 	Change Checkpoint: 100% Code Complete Deadline
17:38:40 <nirik> Changes should be testable now/a few days ago
17:39:12 <ignatenkobrain> so do we need to make decision now or we can make it next week?
17:39:39 <ignatenkobrain> I could ask edynox if we can have it testable within 1-2wks, if not we could just simply move this change to F28
17:39:59 <ecuba> kalev: if SWDB is not in the system and PK with SWDB support is used, then it just logs data to yumdb like before... Then DNF performs the conversion including that data
17:40:19 <sgallagh> Honestly, if it's not ready today, I'm inclined to just push it to F28 so you don't have to stress over it.
17:40:19 <kalev> ahh, right
17:40:22 <ignatenkobrain> ha! he's here... didn't notice
17:40:25 <sgallagh> (And it's one fewer thing to go wrong)
17:40:35 <ignatenkobrain> ecuba: so, what's the status of swdb?
17:40:45 <ignatenkobrain> can we get it merged within few days?
17:41:23 <ecuba> ignatenkobrain: we had a talk with jarda about moving it to F28 - pushing it to rawhide after F27 fork and releasing it as update for F27 later - when it is properly tested in rawhide
17:41:26 * nirik has to step away for a few, back soon.
17:41:42 <ignatenkobrain> I'm kinda against backporting this to F27 later...
17:41:49 <ignatenkobrain> Proposal: defer to F28
17:41:56 <ignatenkobrain> sgallagh: maxamillion: nirik: others: ^
17:42:04 <sgallagh> ignatenkobrain: +1, defer to F28.
17:42:17 * kalev nods.
17:42:17 <sgallagh> And thanks for that
17:42:29 <maxamillion> +1 to defer to f28
17:42:32 <Rathann> sure, one thing less to worry about, +1
17:42:34 <jforbes> +1 defer
17:42:42 <ignatenkobrain> Rathann: =)
17:42:43 <jsmith> +1 to defer
17:43:32 <sgallagh> ecuba: Please *do* land it immediately post-branch to give it maximum time to bake in F28, though.
17:43:42 <sgallagh> It's a worthwhile enhancement.
17:43:50 <jsmith> #agreed Defer "Unified database for DNF" to F28 (+1:6,+0:0,-1:0)
17:43:53 <jsmith> OK, next up...
17:44:02 <jsmith> #topic Authselect: new toold to replace authconfig
17:44:02 <jsmith> #link https://fedoraproject.org/wiki/Changes/Authselect
17:44:22 <dazo> s/toold/tool/
17:44:31 <ecuba> sgallagh: will do
17:44:57 <sgallagh> So, as previously discussed, this tool is additive in F27. It will not replace authconfig in anaconda, etc. until at least F28
17:45:17 <dgilmore> where will it be used then?
17:45:27 <Rathann> will there be some documentation to create your own auth config profiles?
17:45:41 <maxamillion> Rathann: +1
17:45:53 <Rathann> the proposed set covers most scenarios, but surely someone will want to do their own thing
17:46:10 <sgallagh> Rathann: My understanding is that this is exactly the case it is trying to avoid.
17:46:21 <sgallagh> And that if you want to do your own thing, you just don't use authselect
17:46:35 <Rathann> oh, it actually says this:
17:46:37 <Rathann> If an administrator has different needs they can create a custom profile and make it accessible by authselect by dropping it in the tool directory.
17:46:37 <sgallagh> It's not going to replace the ability to edit nsswitch/PAM stacks directly
17:47:03 <Rathann> so, +1 as long as there's documentation on how to create those
17:47:21 <sgallagh> Well, it's still going to be somewhat more limited than today.
17:47:31 <sgallagh> To help constrain the supportable uses
17:48:02 * sgallagh still wants to slap people who try to use pam_fprintd with SSSD for remote logins.
17:48:16 * jsmith blinks
17:48:24 <Rathann> authselect is not in Fedora yet
17:48:27 <dgilmore> sgallagh: I wish that I could :P
17:49:00 <Rathann> however, there is a review request: https://bugzilla.redhat.com/show_bug.cgi?id=1477134
17:49:21 <sgallagh> dgilmore: There are ways to use biometric devices based on smart-cards. That is supportable :)
17:49:22 <Rathann> I wonder why it's not mentioned on the change proposal page
17:49:32 <dgilmore> sgallagh: :)
17:50:06 <dgilmore> I think at this point I am not sure what the change is doing, other than saying this is cooming to a release soon
17:50:06 <jsmith> In the interest of time, does someone want to make a proposal?
17:50:26 <dgilmore> at which point it should be a change for that release
17:50:57 <dgilmore> proposal: punt to being a system wide change in a future release
17:51:10 <Rathann> dgilmore: from what I understand, it's introducing an alternate way to configure authentication
17:51:18 <Rathann> and just that
17:51:21 <sgallagh> Yes
17:51:25 <Rathann> authconfig is not being removed yet
17:51:50 <sgallagh> Proposal: Reject as a change since it's effectively just a new package. Repropose as a Change when it's time to replace authconfig.
17:52:32 <dgilmore> sgallagh: +1
17:52:35 <Rathann> hm, fair enough
17:52:36 <jsmith> I guess I can be +1 to that
17:52:48 <Rathann> +1
17:53:10 <maxamillion> sgallagh: +1
17:53:25 <jforbes> +1 sgallagh
17:54:00 * nirik reads u
17:54:09 <nirik> p
17:54:29 <nirik> +1
17:55:37 <jsmith> #agreed "New tool to replace Authconfig" is rejected, as it's effectively just a new package.  Repropose as a Change when it's time to replace authconfig (+1:7,+0:0,-1:0)
17:55:41 <jsmith> Next up...
17:55:54 <jsmith> #topic New default cipher in OpenVPN
17:55:54 <jsmith> #link https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN
17:56:02 * dazo is the change owner of that one
17:56:51 <sgallagh> dazo: Can you summarize the compatibility between 2.4 and 2.3 clients and servers?
17:57:00 <sgallagh> I'm having trouble parsing it from the Proposal page
17:57:01 <dazo> It should just work :)
17:57:25 <jforbes> I really don't like the fact that this is in a .service file instead of /etc, but it really isn't relevant to this change
17:57:29 <nirik> have the openvpn maintainer(s) approved of the change, or are you one dazo ?
17:57:36 <sgallagh> So no problem with 2.3 clients connecting to a 2.4 with this new default?
17:57:37 <dazo> I am the maintainer
17:57:56 <sgallagh> And no problem with an updated 2.4 client connecting to an older 2.3 server?
17:57:56 <dazo> it should not be any problems for 2.3 clients to connect to 2.4 clients with this change
17:58:00 * jsmith has read the page several times, and is +1 to the change
17:58:00 <nirik> cool. Then +1
17:58:28 <Rathann> I like the change, but why cannot it be done in upstream code instead of via explicit parameter setting in the systemd unit?
17:58:30 <dazo> and if client updates to 2.4, it gets AES-GCM by default ..... and 2.3 clients can add --cipher AES-256-GCM to switch away from BF-CBC
17:58:35 <dazo> (and it would still work)
17:59:02 <sgallagh> dazo: Would work to connect to 2.3 servers silently, or requiring user intervention?
17:59:11 <Rathann> the documentation entry is kind of cryptic
17:59:12 <dazo> Rathann: we're working on a more comprehensive fix, but that needs to be done more carefully - as that is the C code changing
17:59:39 <Rathann> dazo: fair enough
17:59:47 <dazo> sgallagh: no change needed ... but if users decides to migrate to better ciphers, they can do that on a one-by-one approach
17:59:52 <sgallagh> ok
17:59:56 <sgallagh> Then I'm +1
18:00:00 <Rathann> +1 from me
18:00:10 <jforbes> +1 here
18:00:12 <sgallagh> dazo: Thank you for helping clarify
18:00:26 <dazo> Rathann: I'm willing to improve the cryptic docs ... but we can discuss that afterwards
18:00:42 <dazo> (it's hard to be less cryptic when you don't see the crypticness yourself :) )
18:00:50 <jsmith> #agreed "New default cipher in OpenVPN" is approved (+1:5,+0:0,-1:0)
18:00:52 <jsmith> Next up...
18:01:04 <jsmith> #topic Chinese Serif Fonts
18:01:04 <jsmith> #link https://fedoraproject.org/wiki/Changes/ChineseSerifFonts
18:01:41 <nirik> +1
18:01:45 <jsmith> I'm +1 -- seems rational
18:01:55 <Rathann> +1, but why does it need to be a change?
18:02:03 <maxamillion> +1
18:02:08 <jforbes> +1
18:02:24 <Rathann> it's a bit like authselect
18:02:47 <sgallagh> +1
18:02:55 <maxamillion> Rathann: yeah, that's a fair point
18:02:59 <ignatenkobrain> those Chineese guys not having Serif fonts ;)
18:03:06 <Rathann> and how to test section could use real examples to test
18:03:08 <ignatenkobrain> s/Chineese/Chinese/
18:03:27 <Rathann> like *which* Chinese website looks different (better?) when these fonts are available
18:03:49 <sgallagh> This is such a low-risk change that I'd rather just wave it through and move on, personally :)
18:04:51 <jsmith> #agreed "Chinese Serif Fonts" is approved (+1:6,+0:0,-1:0)
18:04:54 <jsmith> Next up...
18:05:05 <jsmith> #topic libpinyin 2.1
18:05:05 <jsmith> #link https://fedoraproject.org/wiki/Changes/libpinyin2.1
18:05:51 <Rathann> ok, this looks like a real change
18:06:59 <nirik> +1
18:07:03 <jsmith> I'm +1
18:07:09 <maxamillion> +1 here as well
18:07:15 <Rathann> doesn't really explain why you need to type less with the new method, but I assume it's obvious to Chinese users
18:07:56 <Rathann> +1
18:07:57 <sgallagh> I don't really like the lack of a contingency plan.
18:08:12 <Rathann> it says revert to old package versions
18:08:52 <jforbes> +1
18:08:55 <sgallagh> I also don't know enough about IME to know if this is really self-contained or if other packages need to start linking to libpinyin
18:10:15 <sgallagh> I'm +0 simply because I don't have enough domain-specific-knowledge here
18:10:49 <maxamillion> yeah, that's fair ... I don't know the reach of it either
18:11:09 <jsmith> #agreed "libpinyin 2.1" is approved (+1:5,+0:1,-1:0)
18:11:14 <jsmith> Next up...
18:11:22 <jsmith> #topic Platform Python Stack
18:11:22 <jsmith> #link https://fedoraproject.org/wiki/Changes/Platform_Python_Stack
18:11:29 <puiterwijk> sgallagh: that should not be needed I think
18:11:30 <jsmith> (We're almost done, I promise...)
18:12:03 <cstratak> I'm here if you have any questions about platform python
18:12:17 <sgallagh> OK, so this is a dependency for the modularity efforts
18:12:30 <sgallagh> To allow system tools to have a stable, known version of python 3 to rely on.
18:12:42 <sgallagh> And then be able to swap out the rest of the python stack as needed.
18:13:06 <sgallagh> I've been following this effort for a while, and I'm pretty comfortable with the plan. +1 from me
18:14:00 <jsmith> Seems reasonable to me, +1
18:14:13 <maxamillion> yeah, seems reasonable
18:14:14 <maxamillion> +=
18:14:17 <maxamillion> +1 *
18:14:18 <jforbes> I read through most of this after an unrelated pythonthing, it makes sense
18:14:20 <jforbes> +1
18:14:35 <nirik> +1 here. sad to go through some of the effort again, but oh well.
18:14:55 <Rathann> so how is that *different* from the current system-python?
18:15:08 <cstratak> Rathann, it's a replacement basically
18:16:00 <cstratak> essentially a new package will be created that dnf and it's dependencies will be able to depend on in the modular world
18:16:04 <Rathann> ok, but I can see that current python3 depends on system-python-libs and this proposal claims it'll be an independent module now
18:16:06 <sgallagh> Rathann: Also, system-python as a term is starting to be used for something else upstream
18:16:12 <sgallagh> So the name needs to change
18:16:16 <Rathann> or do I misunderstand something
18:16:27 <Rathann> right, no questions about the new name
18:16:33 <Rathann> and thanks for referencing upstream PEP
18:17:26 <Rathann> so will the plain python3 package depend on the new platform-python(-libs)?
18:17:37 <sgallagh> Rathann: platform-python *itself* will no longer be a subpackage of the python3 SRPM
18:17:43 <Rathann> like it does on system-python-libs now?
18:17:46 <sgallagh> It'll be maintained separately and stably
18:17:59 <cstratak> platfrom python and python3 will be separate packages
18:18:06 <sgallagh> cstratak can confirm, but the intent is for them to be completely independent
18:18:19 <Rathann> ok
18:18:26 <cstratak> different srpm's basically
18:18:33 <dgilmore> so thats different to before
18:18:50 <Rathann> +1
18:19:36 <jsmith> #agreed "Platform Python Stack" is approved (+1:6,+0:0,-1:0)
18:20:01 <jsmith> #topic OpenSSH Server Crypto Policy
18:20:01 <jsmith> #link https://fedoraproject.org/wiki/Changes/OpenSSH_Server_Crypto_Policy
18:21:21 <Rathann> ugh, depending on predefined comment in the config file?
18:21:26 <Rathann> is there really no better way?
18:21:27 <jsmith> I guess I'm leaning towards +1 for this, but would love to hear any concerns that someone might have
18:21:42 <sgallagh> So, I guess it will change the config for anyone who hasn't manually modified their config in the past. So there might be some limited breakage for clients that are trying to use the older algorithms
18:22:12 <Rathann> I'd have hoped openssh developed support for /etc/ssh/sshd_config.d/foo drop-ins by now
18:22:26 <Rathann> *sigh*
18:22:30 <sgallagh> Rathann: openssh upstream is... difficult about modifications of any kind
18:23:01 <nirik> +1 here
18:23:09 <Rathann> can I at least ask for some documentation on what to put in my own modified sshd_config to achieve the same thing?
18:23:18 <sgallagh> I suspect that any breakage we see would likely be with REALLY old clients connecting to the new server, and I'm okay with that. +1
18:23:34 <dgilmore> +1 here. I would like to see them work withupstream to make it simpler
18:23:35 <nirik> Rathann: definitely.
18:23:36 <sgallagh> Rathann: Like... a .rpmnew file?
18:23:43 <dgilmore> but given what is there now
18:23:48 <Rathann> sgallagh: right, thanks
18:23:54 <maxamillion> +1
18:23:55 <Rathann> +1, then
18:24:23 * Rathann notes that the Release Notes section is empty
18:24:40 <Rathann> and I guess there should be something there
18:24:42 <jforbes> +1
18:25:03 <jsmith> Rathann: Agreed
18:26:55 <dgilmore> Rathann: indeed there should be, but thats not a requirement at this point in time
18:27:02 <Rathann> right
18:27:15 <dgilmore> they have to have the release notes info as the completion deadlines loom
18:28:13 <jsmith> #agreed "OpenSSH Server Crypto Policy" is approved (+1:6,+0:0,-1:0)
18:28:23 <jsmith> #topic #1752 Dealing with non reviewed Changes after "Completion deadline (testable)" check point
18:28:24 <jsmith> .fesco 1752
18:28:24 <jsmith> #link https://pagure.io/fesco/issue/1752
18:28:26 <zodbot> jsmith: Issue #1752: Dealing with non reviewed Changes after "Completion deadline (testable)" check point - fesco - Pagure - https://pagure.io/fesco/issue/1752
18:29:04 <jsmith> I *think* we've done all the sub-bullets under this...
18:29:28 <jforbes> Yup
18:29:30 <jsmith> Other than agree to push the deadline out one week for the items
18:29:33 <jsmith> (obviously)
18:31:19 <dgilmore> we rejected most of them
18:32:04 <dgilmore> but i am +1 to the ones accepted
18:33:02 * nirik nods. me too
18:33:10 <maxamillion> same
18:33:57 <jsmith> I'm obviously +1 for it
18:34:18 <jsmith> Couple more votes, and we can call it good, and wrap up the meeting
18:34:21 <Rathann> +1
18:34:42 <jsmith> sgallagh, jforbes, kalev: Thoughts?
18:34:51 <jforbes> +1
18:34:59 <dgilmore> jsmith: I have one thing for open floor, that may need a issue opened and more discussion
18:35:04 <jsmith> OK.
18:35:06 <sgallagh> +1
18:35:55 <jsmith> #agreed #1752: Give items approved today one more week for Completion deadline (+1:7,+0:0,-1:0)
18:35:59 <jsmith> #topic Next week's chair
18:36:13 <jsmith> If I remember correctly, someone volunteered to take this week
18:36:21 <jsmith> Was it you, sgallagh?
18:36:21 * dgilmore would, but is on PTO next Friday
18:36:27 <dgilmore> jsmith: I think it was
18:36:35 <sgallagh> Yes
18:36:39 <sgallagh> I'll take it next week.
18:36:42 <jsmith> #agreed sgallagh to chair next week
18:36:46 <jsmith> #topic Open Floor
18:36:51 <jsmith> dgilmore: Take it away!
18:37:48 <dgilmore> so it seems that this week was not the first time we were not fully up2date on the schedule
18:38:05 <dgilmore> So I think it wuold be useful to make a small change to the meeting schedule
18:38:31 <dgilmore> and start with a reminder of deadlines passed in the last week, and ones coming in the next week or two
18:38:53 <nirik> sounds reasonable
18:38:55 <sgallagh> By meeting schedule you mean meeting agenda? Or am I misunderstanding?
18:39:00 <dgilmore> perhaps even doing things like calling out in the agenda that change deadlines are upcoming so get them submitted etc
18:39:09 <dgilmore> sgallagh: yes the agrenda
18:39:13 <dgilmore> agenda
18:39:20 <sgallagh> Just making sure I was following. Thanks
18:39:30 <maxamillion> dgilmore: +1
18:39:49 * dgilmore is happy to adjust the templates
18:40:14 <jforbes> Seems worthwhile
18:40:14 <maxamillion> dgilmore++
18:40:14 <zodbot> maxamillion: Karma for ausil changed to 3 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:40:15 <jforbes> +1
18:40:19 <maxamillion> I like it
18:40:25 <jsmith> +1
18:40:34 <Rathann> good idea, +1
18:41:10 <sgallagh> Works for me. +1
18:42:07 <nirik> +1
18:42:19 <dgilmore> jsmith: ¡fin!
18:42:37 <jsmith> Any other topics for the open floor?
18:42:48 <jsmith> If not, I'll end the meeting in a minute (and finally get some lunch)
18:43:56 <dgilmore> #agreed FESCo meeting agenda to be updated to include last weeks schedule deadlines and upcoming deadlines (1:7 0:0 -1:0)
18:44:04 <dgilmore> get that in the notes
18:44:15 <jsmith> :-)
18:44:17 <dgilmore> #action dgilmore to update the wiki page for meetings
18:44:33 <jsmith> Ok, thanks everyone for an epic meeting!
18:44:35 <jsmith> #endmeeting