11:22 a.m.
===================================
#fedora-meeting: FESCO (2017-12-01)
===================================
Meeting started by nirik at 16:00:04 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2017-12-01/fesco.2017-12...
.
Meeting summary
---------------
* init process (nirik, 16:00:04)
* #1792 bodhi enablement and Beta freeze need to be the same day
(nirik, 16:03:37)
* LINK: https://pagure.io/fesco/issue/1794 (nirik, 16:03:37)
* AGREED: fesco agrees to change the bodhi activation date to be the
same day as beta freeze moving forward. (+7,0,2) (nirik, 16:06:57)
* #1790 Proposal for 3 week freeze (nirik, 16:07:10)
* LINK: https://pagure.io/fesco/issue/1790 (nirik, 16:07:10)
* ACTION: nirik to file taskotron ticket to remove or reduce in
importance the upgrade path check (nirik, 16:29:33)
* AGREED: Add 1 week to beta freeze, and review after Fedora 28
release to see if it was worth while (+5, 2, 2) (nirik, 16:32:23)
* #1761 Update of "Fedora Release Live Cycle" and "Changes/ Policy"
(nirik, 16:32:38)
* LINK: https://pagure.io/fesco/issue/1761 (nirik, 16:32:38)
* 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) (nirik, 16:40:15)
* #1767 F28 Self Contained Changes (nirik, 16:40:20)
* LINK: https://pagure.io/fesco/issue/1767 (nirik, 16:40:20)
* AGREED: both f28 self contained changes are approved. (+7,0,2)
(nirik, 16:42:17)
* #1795 F28 System Wide Change: time-1.8 (nirik, 16:42:22)
* LINK: https://pagure.io/fesco/issue/1795 (nirik, 16:42:22)
* AGREED: Change is approved (7,0,2) (nirik, 16:44:56)
* #1796 Mandatory Release notes for Changes (nirik, 16:45:15)
* LINK: https://pagure.io/fesco/issue/1796 (nirik, 16:45:15)
* AGREED: Mandatory release notes are approved (+7,0,2) (nirik,
16:48:16)
* #1798 F28 System Wide Change: Improved Laptop Battery Life (nirik,
16:48:28)
* LINK: https://pagure.io/fesco/issue/1798 (nirik, 16:48:28)
* AGREED: Change is approved (+7,0,2) (nirik, 16:51:02)
* #1663 How strongly should we recommend systemd sandboxing features?
(nirik, 16:51:18)
* LINK: https://pagure.io/fesco/issue/1663 (nirik, 16:51:18)
* 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) (nirik, 17:10:35)
* next weeks chair (nirik, 17:11:40)
* jsmith to chair next week (nirik, 17:12:02)
* Open Floor (nirik, 17:12:11)
* Election nominations are ongoing. Please nominate yourself or
others. :) (nirik, 17:12:39)
* 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.
(nirik, 17:13:25)
Meeting ended at 17:15:18 UTC.
Action Items
------------
* nirik to file taskotron ticket to remove or reduce in importance the
upgrade path check
Action Items, by person
-----------------------
* nirik
* nirik to file taskotron ticket to remove or reduce in importance the
upgrade path check
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (108)
* bowlofeggs (39)
* dgilmore (37)
* jforbes (31)
* kalev (27)
* maxamillion (21)
* zodbot (20)
* tyll (17)
* zbyszek (7)
* jsmith_work (3)
* smooge (1)
* sgallagh (0)
* jsmith (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
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(a)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(a)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(a)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(a)electronsweatshop.com>
16:02:22 <maxamillion> .hello2
16:02:23 <zodbot> maxamillion: maxamillion 'Adam Miller'
<maxamillion(a)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#Propos...
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