=================================== #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-01-16.00.log.html . 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' <opensou...@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' <klem...@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' <jfor...@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' <ra...@electronsweatshop.com> 16:02:22 <maxamillion> .hello2 16:02:23 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamill...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
