16:00:04 <nirik> #startmeeting FESCO (2017-12-01)
16:00:04 <zodbot> Meeting started Fri Dec  1 16:00:04 2017 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <zodbot> The meeting name has been set to 'fesco_(2017-12-01)'
16:00:04 <nirik> #meetingname fesco
16:00:04 <zodbot> The meeting name has been set to 'fesco'
16:00:04 <nirik> #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh bowlofeggs tyll
16:00:04 <zodbot> Current chairs: bowlofeggs dgilmore jforbes jsmith kalev maxamillion nirik sgallagh tyll
16:00:04 <nirik> #topic init process
16:00:22 <tyll> .hello till
16:00:23 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
16:00:45 <nirik> who all is around for a fesco meeting? due to continued DST confusion I'll wait a while for quorom.
16:00:55 <kalev> .hello kalev
16:01:00 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:01:04 <tyll> FYY: Today I only have time for ca. 55 minutes
16:01:12 <jforbes> .hello jforbes
16:01:13 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:01:22 <jforbes> Well, mostly here, in 2 meetings ATM
16:01:38 <nirik> tis the season or something. ;)
16:01:47 <bowlofeggs> .hello2
16:01:48 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
16:02:22 <maxamillion> .hello2
16:02:23 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:02:26 <nirik> ok, thats quorum... I guess we can go ahead and get started.
16:03:37 <nirik> #topic #1792 bodhi enablement and Beta freeze need to be the same day
16:03:37 <nirik> .fesco 1792
16:03:37 <nirik> https://pagure.io/fesco/issue/1794
16:03:38 <zodbot> nirik: Issue #1792: Beta Freeze and Bodhi activation should be on the same date. - fesco - Pagure - https://pagure.io/fesco/issue/1792
16:03:39 <dgilmore> hi all
16:04:12 * nirik has no objection to this. Seems fine to me...
16:04:23 * dgilmore is clearly in favour
16:04:59 <bowlofeggs> no objections here
16:05:16 * kalev has no objections either.
16:05:54 <nirik> proposed #agreed fesco agrees to change the bodhi activation date to be the same day as beta freeze moving forward.
16:05:59 <bowlofeggs> +1
16:06:00 <nirik> +1
16:06:02 <maxamillion> +1
16:06:12 <kalev> +1
16:06:14 <dgilmore> +1
16:06:30 <tyll> +1
16:06:40 <jforbes> +1
16:06:57 <nirik> #agreed fesco agrees to change the bodhi activation date to be the same day as beta freeze moving forward. (+7,0,2)
16:07:10 <nirik> #topic #1790 Proposal for 3 week freeze
16:07:10 <nirik> .fesco 1790
16:07:10 <nirik> https://pagure.io/fesco/issue/1790
16:07:12 <zodbot> nirik: Issue #1790: Proposal for 3 week freeze - fesco - Pagure - https://pagure.io/fesco/issue/1790
16:08:00 <nirik> I'm not sure this will help, but we could give it a try.
16:08:38 <maxamillion> yeah, I'm on the fence but I have concerns about the added stress in the Infra Team that pingou brought up
16:08:56 <nirik> well, infra could decide to stick with 2 weeks...
16:08:57 <bowlofeggs> it didn't sound like people on devel were very keen on it
16:09:23 <jforbes> No, and understandably. As a packager, the freeze is a major inconvenience
16:09:44 <jforbes> (Not saying it is not a necessary inconvenience)
16:10:07 <bowlofeggs> does anyone here think it will help?
16:10:11 <nirik> I kinda like the idea of trying what dgilmore suggested...
16:10:18 <nirik> 3 weeks for beta, 2 for final
16:10:21 <bowlofeggs> (i ask because nirik seemed to have some doubts)
16:10:27 * dgilmore thinks that will work well
16:10:33 <nirik> but I'd also be ok not doing it. :)
16:10:36 <dgilmore> which is why I suggested it
16:11:09 <kalev> I'm not super enthusiastic to have all development frozen for an extra week
16:11:42 <jforbes> kalev: it isn't frozen, it just doesn't get to users
16:12:08 <tyll> ideally we will skip less dates and then the effective freeze is shorter :-)
16:12:32 <nirik> it would be nice to have historical data here... when would this have helped ? I guess anywhere we slipped one week (best case)
16:12:42 <dgilmore> kalev: development is not frozen, stablising the release is
16:12:51 <jforbes> Well, ideally, but this seems to be entirely a stab in the dark, with no data to back the request
16:13:04 <dgilmore> given the history, particularry at Beta of slipping and adding it anyway
16:13:05 <kalev> if we do this, I'd like to relax the rules for getting fixes to stable during the freezes
16:13:08 <maxamillion> I'm +1 to dgilmore's suggestion
16:13:25 <dgilmore> kalev: no that defeats the purpose
16:13:50 <nirik> so whats the advantage to having the week up front vs slipping a week? perception?
16:14:36 * nirik is coming around to just not changing it.
16:15:02 <bowlofeggs> i think i'm currently feeling neutral about it
16:15:03 <tyll> I guess it allows to better coordinate what people are doing when unless people are planning for slips anyway
16:15:13 <jforbes> The main reason it causes a problem has nothing to do with the release we are stabilizing and much more to do with the fact that it causes an issue supporting existing releases. We break upgrade path
16:16:01 <tyll> Also it might allow people to do things calmer when they know they have three weeks to stabilize instead of hurrying to make the possibly unrealistic date
16:16:22 <kalev> one advantage I can see with a 3 week freeze is that since it's planned, we can be more relaxed with letting fixes through the freeze in the beginning, and tighten things up as we get further into the freeze
16:16:38 <kalev> right now with the unplanned slips, we can't do that since we don't really know when exactly we're shipping, and it feels like we have to be tight with the rules all the time
16:16:53 <nirik> true...
16:17:52 <jforbes> That still seems to be "we are going to set a rule, but it doesn't really matter" If we extend it, we extend it.  It is still a freeze
16:18:27 <nirik> proposal: a) deny the change, b) add 1 week to beta freeze, c) add one week to both beta and final freeze. votes?
16:18:44 * nirik wants to see if anything has enough votes to pass
16:19:10 <jforbes> Without any data to show that this might actually be helpful I would have to vote a
16:19:27 <tyll> I would be +1 for b) or c)
16:19:34 <kalev> jforbes: in my view a freeze shouldn't be that everything grinds to a halt, but more like we only take important fixes, and there's a team of people reviewing what fixes we take during the freeze
16:20:00 <nirik> well, thats what it is no?
16:20:05 <dgilmore> kalev: not everything grinds to a halt
16:20:08 <jforbes> kalev: that is the current process. FE exists
16:20:19 <bowlofeggs> a) +1, b) +0, c) -1
16:20:50 <dgilmore> We need to ensure that blockers get fixed quickly
16:21:11 <kalev> a) +1, b) +0, c) -1
16:21:30 <dgilmore> a) -1 b) +1 c) 0
16:21:36 <nirik> a) +1, b) +1, c) -1
16:22:10 <jforbes> The real issue has very little to do with the stabilized release though. Is the fix worth an exception? No, but there is no reason that existing released distro users shouldn't get the fix vs waiting for the freeze to end on something they don't use
16:22:29 <maxamillion> a) -1 b) +1 c) -1
16:22:32 <tyll> a) -1 b) +1 c) +1
16:22:36 <dgilmore> jforbes: they get the fix
16:22:46 <jforbes> dgilmore: upgrade path is now broken
16:22:55 <dgilmore> jforbes: updates-testing is enabled and they get updates and fixes every day
16:23:00 <dgilmore> jforbes: no its not
16:23:07 <kalev> has anyone asked QA's opinion about this?
16:23:10 <nirik> so, not sure theres enough votes for anything here. Should we punt this and ask for more historical data and/or ask the next fesco after elections to take it again?
16:23:20 <dgilmore> jforbes: they need to enable updates-testing when updating from stable to branched
16:23:42 <jforbes> kalev: QA commented in the ticket "I'm not entirely sure I agree that the length of the freeze period is the primary cause of delays, but it's difficult to definitely state that it is or it isn't when we haven't tried a longer one."
16:23:43 <nirik> kalev: adamw chimed in on the ticket: "I'm not entirely sure I agree that the length of the freeze period is the primary cause of delays, but it's difficult to definitely state that it is or it isn't when we haven't tried a longer one."
16:23:48 <bowlofeggs> one more vote for b would get it
16:24:03 <bowlofeggs> if i'm tallying correctly
16:24:10 <bowlofeggs> has everyone voted?
16:24:14 <nirik> upgrade path isn't as important as it used to be... upgrades use distro-sync now.
16:24:26 <jforbes> dgilmore: I understand the process, but when you push something to stable, the tools complain loudly
16:24:46 <jforbes> nirik: then the tools need to be fixed to reflect that, and I have no issues
16:25:11 <nirik> jforbes: the only thing I am aware of is taskotron might still complain with a test...
16:25:25 <jforbes> nirik: it does
16:26:40 <nirik> we should ask that to be advisory/not done anymore. ;)
16:26:47 <nirik> anyhow... lets see...
16:27:18 <nirik> I think everyone voted... jforbes was +1 for a... but how about b or c?
16:28:34 <jforbes> provided taskotron is updated I can go with the flow. It is basically an experiment. If we extend it we should also have a review after the next release to see if it was worth while
16:28:40 <nirik> jforbes: if you are +1 to b) it passes... otherwise I guess we punt. ;)
16:28:59 <nirik> fair
16:29:33 <nirik> #action nirik to file taskotron ticket to remove or reduce in importance the upgrade path check
16:29:34 <jforbes> So proposal: Add 1 week to beta freeze, and review after Fedora 28 release to see if it was worth while
16:29:46 <dgilmore> +1
16:29:46 <nirik> +1
16:30:07 <jforbes> +1
16:30:17 <tyll> +1
16:30:24 <kalev> +0
16:30:41 <maxamillion> +1
16:31:38 <nirik> bowlofeggs: ?
16:32:02 <bowlofeggs> +0
16:32:23 <nirik> #agreed Add 1 week to beta freeze, and review after Fedora 28 release to see if it was worth while (+5, 2, 2)
16:32:38 <nirik> #topic #1761 Update of "Fedora Release Live Cycle" and "Changes/ Policy"
16:32:38 <nirik> .fesco 1761
16:32:38 <nirik> https://pagure.io/fesco/issue/1761
16:32:40 <zodbot> nirik: Issue #1761: Update of "Fedora Release Live Cycle" and "Changes / Policy" - fesco - Pagure - https://pagure.io/fesco/issue/1761
16:33:52 <nirik> I am still pretty fuzzy on the string freeze, but otherwise looks ok to me.
16:34:24 <bowlofeggs> iirc, we didn't get a ton of feedback on the string freeze
16:34:26 <dgilmore> with the move of bodhi activation to beta freeze yep
16:34:32 <maxamillion> +1
16:34:41 <dgilmore> sting freeze I am still not clear what should be done
16:34:54 <dgilmore> the input from the transation team was not super useful
16:35:10 <jforbes> there wasn't much
16:36:59 <nirik> proposal: with addition of 3 weeks for beta freeze and bodhi activation point moving to beta freeze the new release life cycle and changes policy are approved.
16:37:14 <kalev> +1
16:37:15 <bowlofeggs> +1
16:37:20 <dgilmore> +1
16:37:25 <tyll> +1
16:37:33 <nirik> +1
16:37:50 <jforbes> +1
16:38:48 <nirik> maxamillion: ?
16:40:15 <nirik> #agreed with addition of 3 weeks for beta freeze and bodhi activation point moving to beta freeze the new release life cycle and changes policy are approved. (+6,0,3)
16:40:20 <nirik> #topic #1767 F28 Self Contained Changes
16:40:20 <nirik> .fesco 1767
16:40:20 <nirik> https://pagure.io/fesco/issue/1767
16:40:23 <zodbot> nirik: Issue #1767: F28 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1767
16:40:40 <maxamillion> nirik: sorry
16:40:44 <nirik> we have Erlang 20 and php 7.2
16:40:47 <nirik> maxamillion: no worries.
16:40:58 <nirik> +1 to both here
16:41:07 <maxamillion> +1 to both
16:41:13 <dgilmore> +1 to both
16:41:21 <jforbes> +1 to both
16:41:41 <kalev> +1 to both
16:41:46 <tyll> +1 to both
16:42:08 <bowlofeggs> +1 to both, though they used my old FAS name on one of them
16:42:17 <nirik> #agreed both f28 self contained changes are approved. (+7,0,2)
16:42:22 <nirik> #topic #1795 F28 System Wide Change: time-1.8
16:42:22 <nirik> .fesco 1795
16:42:22 <nirik> https://pagure.io/fesco/issue/1795
16:42:23 <zodbot> nirik: Issue #1795: F28 System Wide Change: time-1.8 - fesco - Pagure - https://pagure.io/fesco/issue/1795
16:43:11 <nirik> sure, +1. Format has changed, but meh
16:43:23 <kalev> +1
16:43:42 <maxamillion> does the format change break anything?
16:43:45 <dgilmore> +1
16:43:55 <bowlofeggs> +1
16:44:00 <maxamillion> omg I <3 the new wiki theme so much
16:44:11 <nirik> unknown. Possibly some scripts. they could call it with -p to get the old format/behavior
16:44:19 <maxamillion> nirik: fair
16:44:26 <maxamillion> yeah, I'm +1
16:44:49 <bowlofeggs> i alos love the wiki
16:44:50 <tyll> +1
16:44:56 <nirik> #agreed Change is approved (7,0,2)
16:44:58 <jforbes> I think +1 works
16:44:59 <bowlofeggs> ryanlerch is the man
16:45:05 <maxamillion> ryanlerch++
16:45:06 <zodbot> maxamillion: Karma for ryanlerch changed to 6 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:45:15 <nirik> #topic #1796 Mandatory Release notes for Changes
16:45:15 <nirik> .fesco 1796
16:45:15 <nirik> https://pagure.io/fesco/issue/1796
16:45:18 <zodbot> nirik: Issue #1796: Mandatory Release notes for Changes - fesco - Pagure - https://pagure.io/fesco/issue/1796
16:45:57 <dgilmore> I think it is fair
16:46:05 <tyll> +1 Changes are primarily there to properly communicate new things so proper release notes make sense
16:46:12 <nirik> +1 here.
16:46:17 <bowlofeggs> +1
16:46:23 <dgilmore> +1
16:46:29 <jforbes> +1
16:47:31 <kalev> +1
16:48:14 <maxamillion> +1
16:48:16 <nirik> #agreed Mandatory release notes are approved (+7,0,2)
16:48:28 <nirik> #topic #1798 F28 System Wide Change: Improved Laptop Battery Life
16:48:28 <nirik> .fesco 1798
16:48:28 <nirik> https://pagure.io/fesco/issue/1798
16:48:37 <zodbot> nirik: Issue #1798: F28 System Wide Change: Improved Laptop Battery Life - fesco - Pagure - https://pagure.io/fesco/issue/1798
16:49:15 <nirik> I'm happy someone is working on this. ;) Even tho the bluetooth thing doesn't work on my laptop... +1 to the change.
16:49:41 <dgilmore> +1
16:49:59 <bowlofeggs> i am opposed to having better battery life on my laptop
16:50:08 <bowlofeggs> because i am being secretly paid by the energy industry
16:50:14 <dgilmore> I am opposed to bowlofeggs opposing
16:50:16 <maxamillion> bowlofeggs: I KNEW IT
16:50:18 <bowlofeggs> hahah jk
16:50:19 <maxamillion> +1
16:50:20 <bowlofeggs> +1
16:50:21 <tyll> +1
16:50:26 <kalev> +1
16:50:49 <jforbes> I am +1
16:51:02 <nirik> #agreed Change is approved (+7,0,2)
16:51:18 <nirik> #topic #1663 How strongly should we recommend systemd sandboxing features?
16:51:18 <nirik> .fesco 1663
16:51:18 <nirik> https://pagure.io/fesco/issue/1663
16:51:30 <zodbot> nirik: Issue #1663: How strongly should we recommend systemd sandboxing features? - fesco - Pagure - https://pagure.io/fesco/issue/1663
16:51:50 * nirik waits for pagure
16:51:55 * zbyszek is here just in case
16:52:52 <bowlofeggs> that nonewprivileges bug was actually affecting my ejabberd package
16:52:55 <bowlofeggs> glad they fixed that
16:53:13 <jforbes> ISE
16:53:18 <bowlofeggs> s/my/our/ :)
16:54:15 <nirik> so I assume we would ask FPC to add these best practices (and one must) to guidelines?
16:54:23 <maxamillion> probably
16:54:34 <kalev> one concern I have here is that a whole bunch of fedora packagers are just that, people packaging up upstream code and don't really know how it works internally
16:54:44 <maxamillion> I'm sure we could come up with something, but I think that's more hte FPC wheelhouse
16:54:56 <kalev> and changing how daemons work and interact with systemd might be a bit too hard for them
16:55:03 <bowlofeggs> "Services MUST use PrivateTmp, ProtectHome, ProtectSystem, unless they are running in a way in which the full file system is not visible through some other means." - are there programs that legitimately need to be able to see these folders that shoudl get exceptions?
16:55:35 <zbyszek> "n all cases, if those protection settings interfere with the operation of the service, they should be skipped, obviously. This SHOULD be documented, either in the .service file or in .spec."
16:55:51 <bowlofeggs> ah i see
16:55:54 <nirik> kalev: well, if nothing else you can use trial and error.... ;) adjust service file, test that the thing still works as expected.
16:56:00 <kalev> true :)
16:56:01 <bowlofeggs> the MUST is weird since that condidtion is at the end
16:56:09 * tyll is still waiting for pagure :-(
16:56:11 <kalev> and then there's awesome zbyszek who can probably help fix things too! :)
16:56:19 <bowlofeggs> tyll: https://fedoraproject.org/wiki/User:Zbyszek/ProtectionsPolicyDraft#Proposed_FESCo_decision
16:56:34 <tyll> bowlofeggs: thx
16:56:55 <nirik> is anyone going to try and update existing packages for this? or it's all up to maintainers as they have cycles?
16:57:59 * dgilmore kinda wishes we had some machine learning bots
16:58:05 <zbyszek> I think it's very hard to do, unless you know the service. Just diving in without knowing allthe use cases and modes is going to end in something that "works on my machine" but breaks users' setups badly.
16:58:19 <dgilmore> that way we could teach them to update the packages and they could go off and do them all
16:58:25 <tyll> I have to leave, but I am +1 for this
16:58:50 <nirik> zbyszek: yeah.
16:59:03 <dgilmore> I am mostly +1 for it.  I am a bit concerned over how this will look in practice
16:59:06 <bowlofeggs> i am +1 here
16:59:24 <bowlofeggs> i might suggest moving the last paragraph to be first
16:59:32 <bowlofeggs> or even like a yellow caution box
16:59:39 * nirik isn't sure we are the best ones to be approving it...
17:00:00 <dgilmore> it is the FPC's realm
17:00:22 <kalev> I think we should maybe be providing guidance what we want here (do we want more service lockdown? I personally would be a big +1)
17:00:24 <jforbes> Oh, has this not gone through FPC yet?
17:00:28 <kalev> and then ask FPC to draft the policy
17:00:56 <zbyszek> jforbes: FPC was asked and bumped the question to Fesco
17:01:01 <dgilmore> I think FESCo should say something like "FESCo recommends that all services take advantage of all possible means for securing the service as practical"
17:01:10 <nirik> zbyszek: ah, missed that.
17:01:26 <kalev> I like it a lot what zbyszek has written up, I just have concerns that our package maintainers may not have the skills to actually implement all this
17:01:27 <maxamillion> +1
17:01:37 <kalev> and because of that, maybe we should tune down the MUSTs a bit
17:02:39 <nirik> so, the 2 musts are the 'network listening has to use a non root user' and 'Services MUST use PrivateTmp, ProtectHome, ProtectSystem' ?
17:03:44 <nirik> is there some way we could just do/enforce those globally and have users opt out if they have a special case?
17:04:14 <nirik> (probibly not at all easily)
17:04:55 <zbyszek> That'd certainly break things. At least running as user needs setting up of permissions in the filesystem and such.
17:05:32 <bowlofeggs> we could file tickets on all packages that have service files and ask them to review theirs for compliance
17:05:43 <bowlofeggs> of course, not everyone would do it
17:05:50 <bowlofeggs> and not everyone would do it correctly
17:05:52 <jsmith_work> (Sorry, not able to make most of the meeting today -- trying to vote in tickets, but Pagure is having some issues)
17:05:55 <bowlofeggs> but could be helpful
17:05:56 <nirik> well, I am happy to say to FPC that we like this draft, but I worry... many maintainers just won't see th musts and not enable them.
17:06:11 <nirik> welcome jsmith_work
17:06:32 <nirik> but I guess it would catch new packages.
17:07:41 <nirik> proposal: draft policy approved and FPC is asked to review and comment and fold into guidelines.
17:08:01 <jforbes> Right, so it becomes a quesiton of what is the time line for enforcement on existing packages?
17:08:14 <jforbes> nirik: +1
17:08:17 <dgilmore> nirik: indeed
17:08:31 <dgilmore> I suspect that a lot of packages will not enable things
17:08:49 <nirik> well, we don't really enforce existing packages, so ∞ I guess...
17:09:31 <nirik> anyhow, +1 to my proposal
17:09:35 <bowlofeggs> nirik: +1
17:09:37 <kalev> +1 to nirik's proposal
17:09:40 <dgilmore> +!
17:09:42 <dgilmore> +1
17:09:55 <kalev> we can always review packages that don't conform at a later date and then see if we can do something to help them along
17:10:16 <maxamillion> +1
17:10:35 <nirik> #agreed draft policy approved and FPC is asked to review and comment and fold into guidelines. (8,0,1) (jsmith was +1 in ticket and tyll was +1 before leaving)
17:10:46 <dgilmore> kalev: or we can teach bots to do it all for us :D
17:10:53 <nirik> zbyszek: can you take this back to FPC now and let us know if they have any issues with it?
17:11:23 <kalev> dgilmore: or that! :)
17:11:31 <zbyszek> Sure.
17:11:40 <nirik> #topic next weeks chair
17:11:46 <nirik> who wants it next week?
17:11:53 <nirik> zbyszek++ thanks!
17:11:53 <zodbot> nirik: Karma for zbyszek changed to 1 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:11:53 <jsmith_work> I can
17:12:02 <nirik> #info jsmith to chair next week
17:12:03 * jsmith_work hasn't run the meeting in a while
17:12:03 <zbyszek> thank you all
17:12:06 <nirik> thanks jsmith_work
17:12:11 <nirik> #topic Open Floor
17:12:20 <nirik> I had 2 short informational items...
17:12:39 <nirik> #info Election nominations are ongoing. Please nominate yourself or others. :)
17:13:16 <bowlofeggs> i nominate larry ellison
17:13:21 <smooge> I second
17:13:25 <nirik> #info next week Fedora Infrastructure is doing a datacenter move. see announcements for more info and https://www.fedorastatus.org/q4maint.html for whats what day.
17:13:48 <nirik> bowlofeggs: sorry, he's off on his hawaian island.
17:14:06 <nirik> anyone have any additional open floor items?
17:14:27 <jforbes> I want a hawaiian island
17:14:29 <dgilmore> nada
17:15:15 <nirik> ok, thanks for coming everyone!
17:15:18 <nirik> #endmeeting