16:00:29 <maxamillion> #startmeeting FESCO (2016-08-19)
16:00:29 <zodbot> Meeting started Fri Aug 19 16:00:29 2016 UTC.  The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:29 <zodbot> The meeting name has been set to 'fesco_(2016-08-19)'
16:00:37 <maxamillion> #meetingname fesco
16:00:37 <zodbot> The meeting name has been set to 'fesco'
16:00:37 <maxamillion> #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann
16:00:37 <zodbot> Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh
16:00:40 <maxamillion> #topic init process
16:00:43 <maxamillion> .hello maxamillion
16:00:43 <sgallagh> .hello sgallagh
16:00:44 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:00:47 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:50 <jwb> hi
16:00:50 <nirik> .hello kevin
16:00:51 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:00:51 <Rathann> .hello rathann
16:00:53 <zodbot> Rathann: rathann 'Dominik Mierzejewski' <dominik@greysector.net>
16:00:57 <paragan> .hello pnemade
16:00:59 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
16:01:12 <jsmith> .hello jsmith
16:01:13 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
16:01:14 <kalev> .hello kalev
16:01:15 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:02:45 <maxamillion> alright, we're good on attendance, stragglers might roll in later
16:03:01 <maxamillion> #topic Follow Ups
16:03:14 <maxamillion> #topic #1605 finish retirement of sysvinit-only packages
16:03:23 <maxamillion> .fesco 1605
16:03:25 <zodbot> maxamillion: #1605 (finish retirement of sysvinit-only packages) – FESCo - https://fedorahosted.org/fesco/ticket/1605
16:03:28 <maxamillion> .fesco 1605
16:03:31 <maxamillion> grrr
16:03:31 <zodbot> maxamillion: #1605 (finish retirement of sysvinit-only packages) – FESCo - https://fedorahosted.org/fesco/ticket/1605
16:03:35 <maxamillion> https://fedorahosted.org/fesco/ticket/1605
16:03:42 <sgallagh> Sounds like this is basically done, I think.
16:03:48 <nirik> I think it's all done.
16:03:51 <jwb> yes
16:03:57 <paragan> so close the ticket?
16:04:00 <nirik> surprisingly a number of the packages got picked up and fixed. ;)
16:04:01 <maxamillion> +1
16:04:04 <jsmith> :-)
16:04:12 <paragan> nirik, yeah I too observed that
16:04:19 <kalev> looks like the strategy worked :)
16:04:26 <paragan> mostly by ellert
16:04:31 <nirik> if thats what it takes to motivate, sure. ;)
16:04:55 <maxamillion> is someone closing or should I?
16:06:21 <nirik> go ahead.
16:07:23 <maxamillion> alright, moving on
16:07:23 <maxamillion> #topic #1606 F25 approved Changes not in MODIFIED status
16:07:23 <maxamillion> .fesco 1606
16:07:23 <maxamillion> https://fedorahosted.org/fesco/ticket/1606
16:07:24 <zodbot> maxamillion: #1606 (F25 approved Changes not in MODIFIED status (considered as not testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1606
16:08:53 <jsmith> I'm not particularly tied to any of the ones not yet set to MODIFIED...
16:09:17 <jsmith> So if it were up to me, I'd say to defer them to F26
16:09:21 <maxamillion> One of them is mine (BZ#1345757) but I updated it yesterday, I have things in a testable state, next step is to work on getting it in Fedora Infra Ansible and request some security audit
16:10:15 <sgallagh> Does anyone know offhand if zbyszek made the KillUserProcesses change in the systemd included in Alpha Freeze?
16:10:29 * maxamillion does not
16:10:30 <jsmith> sgallagh: I don't know :-(
16:10:33 <jwb> is anyone from rel-eng here to talk about the koji ticket?
16:10:56 <maxamillion> me ... ish
16:11:00 <sgallagh> /me goes to check
16:11:14 <nirik> I don't see it off hand
16:11:39 <paragan> jgregusk has not replied to needinfo so his 2 changes should be deferred to f26
16:12:13 <paragan> not sure if we can allow Rust compiler as its waiting on some package review
16:12:36 <sgallagh> --without-kill-user-processes
16:12:49 <sgallagh> systemd appears to have been built without that setting
16:13:15 <maxamillion> paragan: the package review seems to be done, the package is in f25-updates-testing
16:13:15 <sgallagh> Since it's apparently not going to get the alpha testing we requested, shall we defer it?
16:13:38 <maxamillion> paragan: https://bodhi.fedoraproject.org/updates/FEDORA-2016-08169a6354
16:13:59 <maxamillion> it also got pushed to F24 stable :) https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5a0802802
16:14:16 <nirik> sgallagh: I think so yeah.
16:14:25 <jsmith> sgallagh: +1
16:14:47 <paragan> maxamillion, cargo package is still not reviewed
16:14:49 <maxamillion> sgallagh: +1
16:14:52 <maxamillion> paragan: ohhhh ok
16:15:28 <kalev> as much as I'd like to see systemd cleaning up processes, probably best to defer it at this point, yeah
16:16:20 <maxamillion> I'll take on reviewing the cargo package, I'd hate to defer something just because we couldn't find a reviewer ... the review request is a month old, the person working on the change got everything in on time
16:16:28 <sgallagh> +1 to deferring KillUserProcesses for the record
16:16:32 <jwb> maxamillion: so... is koji going to generate the install images or is it a clear defer?
16:16:33 <paragan> maxamillion, +1
16:16:52 <Rathann> +1 to deferring KillUserProcesses as well
16:16:53 <sgallagh> maxamillion: +1
16:16:56 <maxamillion> jwb: that's a dgilmore question, I've not followed that topic very will
16:16:58 <maxamillion> well*
16:17:00 <jwb> +1 to deferring KillUserProcesses
16:17:11 <maxamillion> alright, let's start tallying votes ...
16:17:23 <maxamillion> Proposal: defer KillUserProcess to Fedora 26
16:17:30 <jwb> +1
16:17:31 <nirik> +1
16:17:32 <kalev> +1
16:17:32 <paragan> +1
16:17:35 <sgallagh> +1
16:17:35 <maxamillion> +1
16:17:39 <jsmith> +1
16:18:06 <Rathann> +1
16:18:21 <maxamillion> #agreed defer KillUserProcess to Fedora 26 (+1: 8, -1: 0, +0: 0)
16:18:33 <maxamillion> erm ... I might have miscounted
16:18:43 <maxamillion> #undo
16:18:43 <zodbot> Removing item from minutes: AGREED by maxamillion at 16:18:21 : defer KillUserProcess to Fedora 26 (+1: 8, -1: 0, +0: 0)
16:18:49 <jwb> i count 8
16:18:56 * Rathann counts 8 as well
16:18:58 <paragan> that was right count
16:19:02 <maxamillion> Rathann: what's your FAS name?
16:19:07 <Rathann> rathann
16:19:11 <Rathann> lowercase
16:19:15 <maxamillion> ah
16:19:39 <maxamillion> so, as something who's only on his second time chairing the meeting, do I count non-FESCo votes?
16:19:54 <jwb> Rathann is in fesco
16:19:55 <Pharaoh_Atem> afaik, people like us don't count
16:19:59 <paragan> I think we all are fesco members here
16:20:01 <Pharaoh_Atem> non-fesco folks, that is
16:20:05 <maxamillion> jwb: not on the roster https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee?rd=FESCo#Members
16:20:29 <Rathann> roster wasn't updated after last elections
16:20:30 <kalev> maxamillion: he got elected a few weeks ago and is replacing number80
16:20:32 <jwb> maxamillion: it's a wiki.  it is stale by definition.  he was elected in the recent election like 3 weeks ago
16:20:34 <maxamillion> *sigh*
16:20:37 <Rathann> yup
16:20:40 <jwb> burn all the wikis down
16:20:41 <paragan> maxamillion, well you only pinged him in your initial meeting lines
16:20:42 * Pharaoh_Atem sighs
16:20:43 <sgallagh> maxamillion: He replaced Haikel
16:20:46 <sgallagh> I'll update it
16:20:46 <maxamillion> Rathann: my apologies
16:20:47 <Pharaoh_Atem> we need an API for this
16:20:50 <maxamillion> #agreed defer KillUserProcess to Fedora 26 (+1: 8, -1: 0, +0: 0)
16:20:52 <Rathann> no problem ;)
16:21:21 <maxamillion> my memory is mush, if it's not written down, I'm going to get it wrong
16:21:23 <maxamillion> allllright then
16:21:36 <paragan> next Rust compiler voting?
16:21:52 <maxamillion> Proposal: maxamillion to take the review of cargo to move the rust feature through
16:22:05 <maxamillion> errr s/feature/change
16:22:13 <sgallagh> maxamillion: +1
16:22:14 <maxamillion> +1
16:22:18 <nirik> is that all that is blocking it?
16:22:19 <paragan> maxamillion, +1
16:22:23 <maxamillion> nirik: yes
16:22:37 <maxamillion> nirik: all the work appears to be done
16:22:38 <nirik> sure then, +1 to give it more time.
16:22:41 <Rathann> +1, thanks for volunteering
16:22:44 <maxamillion> nirik: and the review request was filed a month ago
16:22:52 <jwb> +1
16:22:52 <kalev> +1, thanks maxamillion
16:22:59 * Rathann is behind his reviews :(
16:23:18 <maxamillion> jsmith: ?
16:23:24 <jsmith> +1 from me
16:23:27 <jsmith> (sorry for the latency)
16:23:51 <maxamillion> #agreed maxamillion to take the review of cargo to move the rust change through (+1: 8, -1: 0, +0: 0)
16:24:19 <maxamillion> Proposal: defer Koji Generates Installation Media change until Fedora 26
16:24:33 <nirik> +1
16:24:34 <maxamillion> +1
16:24:48 <paragan> +1
16:24:59 <sgallagh> +1
16:24:59 <jwb> +1 i guess
16:25:10 <sgallagh> Can we try to get it done in Rawhide ASAP though?
16:25:13 <kalev> is dgilmore on board with deferring it?
16:25:24 <jwb> kalev: we don't know.  he isn't here.
16:25:30 <kalev> right :)
16:25:37 <jsmith> +1 (reluctantly)
16:25:49 <maxamillion> jsmith: relucantly? ... what's the reservation?
16:25:52 <kalev> +1
16:26:08 <jsmith> maxamillion: I would have liked to have seen it in F25, if it's fully baked...
16:26:14 <maxamillion> jsmith: ah
16:26:16 <jsmith> maxamillion: I just have no idea if it's fully baked
16:26:26 <Rathann> +1, since it's not ready, apparently
16:26:39 <jwb> seems pretty key to the whole release process so i was hoping we'd have info no it
16:26:43 <jwb> s/no/on
16:26:56 <Pharaoh_Atem> it seems somewhat difficult to find out what's going on in koji development
16:27:04 <maxamillion> jsmith: jwb: would you rather we wait until dgilmore & co can chime in?
16:27:10 <maxamillion> Pharaoh_Atem: +1
16:27:15 <jsmith> maxamillion: Yeah, I'm fine with that
16:27:23 <maxamillion> alright
16:27:32 <jsmith> maxamillion: Although, I hate leaving things to crunch-time too...
16:27:36 <jwb> maxamillion: no.  it's either doing it now for Alpha or it isn't.  if it isn't, then it needs to be deferred
16:27:45 <maxamillion> jwb: rgr
16:28:11 <maxamillion> alright, well the votes are in, I just wanted to not have a concern go unvoiced if it was something we needed to re-open for discussion
16:28:41 <maxamillion> #agreed defer Koji Generates Installation Media change until Fedora 26 (+1: 8, -1: 0, +0: 0)
16:29:44 <maxamillion> alright, the other one on there was mine, the RelEng Automation but I updated yesterday and it is currently MODIFIED status ... is there anyone on that one that anyone would like to discuss and/or propose a vote for?
16:30:07 <paragan> if its done lets approve it :)
16:30:38 <maxamillion> Proposal: Approve Release Engineering Automation Workflow Engine Change
16:30:40 <maxamillion> +1
16:30:52 <maxamillion> jsmith: we're voting to approve the Release Engineering Automation Workflow Engine change
16:30:52 <paragan> +1
16:30:57 <jsmith> +1
16:31:10 <nirik> sure, if it's modified now, +1
16:31:10 <kalev> +1
16:31:18 <jwb> +1
16:31:26 <Rathann> +1
16:31:48 <sgallagh> +1
16:32:11 <maxamillion> #agreed Approve Release Engineering Automation Workflow Engine Change (+1: 8, -1: 0, +0: 0)
16:32:22 <maxamillion> moving on
16:32:22 <maxamillion> #topic #1609 Fedora 26 schedule proposal
16:32:22 <maxamillion> .fesco 1609
16:32:22 <maxamillion> https://fedorahosted.org/fesco/ticket/1609
16:32:25 <zodbot> maxamillion: #1609 (Fedora 26 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1609
16:33:28 <maxamillion> anyone have any preliminary thoughts on the schedule? anything needing to be discussed here or should we vote?
16:34:12 <jsmith> I'm for three-weeks for mass rebuild -- anything less is really hard
16:34:26 <Rathann> jsmith: +1
16:34:26 <jwb> we still haven't settled on a schedule to vote on yet
16:34:28 <maxamillion> jsmith: +1
16:34:36 <jsmith> Other than that, I'm "meh"
16:34:37 <nirik> also would be good to get pbrobinson's input on aarch64 merging...
16:34:47 <maxamillion> nirik: true
16:34:49 <jsmith> nirik: Aye :-)
16:34:53 <pbrobinson> ASAP :)
16:34:54 <maxamillion> oy
16:35:00 <maxamillion> pbrobinson: o hai
16:35:14 <pbrobinson> hoping to have aarch64 builders done next week
16:35:27 <kalev> nice
16:35:31 <pbrobinson> once we have that in place we can work our merging
16:35:53 <pbrobinson> so we can start building even if we don't instantly enable it in the compose output
16:36:00 <nirik> so, in any case should land long before a jan mass rebuild
16:36:13 <kalev> I'm personally of the mind that 2 weeks for rebuilds is totally fine, as people can always push fixes to the branched version afterwards as well
16:36:32 <kalev> as long as we don't have any special considerations this time around due to the aarch64 merge affecting rebuilds
16:36:39 <pbrobinson> nirik: yes, wanted it to land ASAP
16:36:41 <jwb> really uncomfortable with a 2 week rebuild
16:36:59 <jwb> particularly if we're delaying it to include GCC 7 and with aarch64 being included in the rebuild
16:37:04 <pbrobinson> nirik: the plan it to land and let it warm into it rather than instantly hit a mass rebuild
16:37:12 <paragan> I think we should have 3 week rebuild
16:37:14 <maxamillion> Proposal: maintain a three week mass rebuild time on the f26 schedule
16:37:16 <pbrobinson> jwb: I agree with that, 2 weeks is tight
16:37:30 <jsmith> kalev: I've heard rel-eng say multiple times that 2 weeks is unreasonable -- I'm giving the benefit the the doubt
16:38:01 <pbrobinson> while generally these days the actual mass rebuild normally kicks on a Friday afternoon and is done by Monday it generally takes a good couple of weeks to clean up any mess
16:38:15 <paragan> right
16:38:38 <kalev> right, but the mess cleaning can continue after branching too
16:38:51 <kalev> do we need to delay branching just because there's still things to clean up?
16:39:27 <sgallagh> It's harder on the maintainers, but honestly not by much.
16:39:27 <maxamillion> it makes the process to fix more combersome because things will feed through bodhi won't it?
16:39:32 <sgallagh> It's a git merge and fedpkg build
16:39:45 <jwb> and a bodhi update and buildroot overrides
16:39:45 <sgallagh> Right, and Bodhi activation.
16:39:50 <jwb> it's a mess
16:40:28 <maxamillion> where as rawhide, but design, is the wild west so you just throw things at koji
16:40:48 <nirik> working things... working things...
16:41:02 <gholms> Heh
16:41:03 <jwb> but in that case, we actually get the benefit of not having to manually override to include things in the buildroot
16:41:15 <jwb> which, depending on what is actually broken, can save a lot of time and confusion
16:41:16 <maxamillion> jwb: right
16:41:26 <maxamillion> I meant that as a positive, not a negative
16:42:05 <kalev> the other alternative is to move all dates leading up to the mass rebuild one week earlier
16:42:56 <nirik> that would put submission deadline at like the 3rd...
16:42:58 <kalev> and I don't think that would fly, since 2017-01-10 "Change Checkpoint: Proposal submission deadline (System Wide Changes)" would then clash with christmas vacations
16:42:59 <pbrobinson> well it means maintainers have to do it twice, once for each branch, and then possibly bodhi as well
16:43:01 <kalev> yeah
16:43:06 <jwb> i don't think we're going to settle this here today to be honest.  we need to line up the proposed schedules in the ticket
16:43:15 <pbrobinson> I find a lot of maintainers have issues with branching without adding extra in
16:43:19 * nirik nods. more in ticket discussion
16:43:26 <kalev> I mean, sure, it would be nicer to have 3 weeks, but we just don't seem to have the luxury this time around
16:43:42 <jwb> yes we do
16:44:06 <jwb> and it isn't a luxury
16:44:33 <maxamillion> alright, let's defer to the ticket then .... shall we move on to the next topic?
16:44:42 <jwb> please
16:44:44 <paragan> yes
16:45:27 <jsmith> WORKSFORME
16:45:36 <maxamillion> #agreed more in ticket discussion needed for schedule, will revisit later
16:45:44 <maxamillion> #topic #1611 Continued lack of support for RPM weak deps in distro tooling
16:45:47 <maxamillion> .fesco 1611
16:45:48 <zodbot> maxamillion: #1611 (Continued lack of support for RPM weak dependencies in distribution tooling) – FESCo - https://fedorahosted.org/fesco/ticket/1611
16:45:49 <maxamillion> https://fedorahosted.org/fesco/ticket/1611
16:46:20 <nirik> so we worked around this immediate issue
16:46:32 <maxamillion> nirik: iirc, you had some follow up on this ticket? something about builds or composes on f24 machines instead of el7
16:46:50 <nirik> yeah, so I did make a bodhi machine that was f24 and tested...
16:47:08 <nirik> doing that is enough to make weak deps appear in the repodata (but not boolean ones)
16:47:29 <nirik> so, we probibly want to move to that so updates is similar to the other path
16:47:40 <maxamillion> is that enough to satisfy the immediate requirements of the ticket or is there a larger issue?
16:47:42 <nirik> but there's still things that don't handle them...
16:47:54 <nirik> like appliance-tools (this ticket)
16:47:59 <maxamillion> ah
16:48:57 <nirik> so I guess I'd say close this ticket... people can still use weak deps and if they hit some case with issues with the compose tools we will try and work around that as best we can until all compose tools handle them correctly.
16:49:27 <maxamillion> nirik: alright, I think you have the most context on this out of the group ... want to make a proposal for vote?
16:49:44 * stickster asks a (potentially) dumb question
16:49:51 <maxamillion> stickster: shoot
16:50:21 <stickster> I was under the impression that there's a PR pending for koji that would make koji use createrepo_c and allow weak deps to be generated there, is that relevant at all here?
16:50:39 <dgilmore> stickster: its still in development
16:50:42 <stickster> perhaps makes this a stopgap
16:50:44 <nirik> stickster: yes, it's been pending for a long time
16:50:48 <dgilmore> and we are not sure it does everything
16:51:03 <dgilmore> it also may not help as it uses yum to do multilib
16:51:18 <jsmith> stickster: That still doesn't fix bohdi either, right?
16:51:32 <dgilmore> jsmith: the plan is to have bodhi use koji signed repos
16:51:42 <stickster> jsmith: not atm, no... but AIUI the plan was for the masher to hand this off to koji signed repos
16:51:47 <stickster> dgilmore: *nod
16:51:52 <jsmith> Ah, I missed that :-)
16:51:54 <nirik> proposal: releng will try and move all compose tools to support weak deps, but in the mean time issues with composes and weak deps will need to be handled on a case by case basis.
16:51:59 <stickster> OK, don't let me pull things off track please
16:52:06 <kalev> nirik: +1
16:52:09 <stickster> I just didn't know if I had completely misunderstood that signed repo work
16:52:21 <Rathann> nirik: +1
16:52:21 <dgilmore> nirik: +1
16:52:33 <jsmith> nirik: +1 from me
16:52:39 <sgallagh> nirik: +1
16:52:40 <dgilmore> stickster: signed repos will use whatever koji is configured for
16:52:46 <paragan> nirik, thanks for your work, +1
16:52:52 <nirik> I'm not sure what all beyond appliance tools would still not support them...
16:52:54 <dgilmore> stickster: so if koji is configured to use createrepo thats what it uses
16:52:59 <maxamillion> nirik: +1
16:53:54 <dgilmore> nirik: signed repos, mash, appliance-creator, and probably some other bits still use yum
16:54:13 <nirik> yeah. hard to say what all, but more...
16:54:27 <maxamillion> alright, who we missing on votes?
16:54:27 <nirik> but createrepo + new rpm is enough to get weak deps ok...
16:54:30 <maxamillion> jwb: ?
16:54:41 <dgilmore> afaik the biggest issue with weak deps is the rpm that bodhi uses
16:54:53 <jwb> +1 to nirik
16:55:07 <dgilmore> which will go away with signed repos
16:55:14 <dgilmore> as that will use fedora's rpm
16:55:17 <maxamillion> we're sill missing one ... we picked up dgilmore in the vote pool
16:55:36 <nirik> dgilmore: or a fedora bodhi-backend...
16:55:38 <maxamillion> oh, nirik
16:55:47 <maxamillion> nirik: I don't think you voted :)
16:55:48 <nirik> +1 to my own proposal. ;)
16:55:48 <dgilmore> nirik: or that
16:56:28 <maxamillion> #agreed releng will try and move all compose tools to support weak deps, but in the mean time issues with composes and weak deps will need to be handled on a case by case basis. (+1: 9, -1: 0, +0: 0)
16:56:42 <dgilmore> Sorry I am late, I was going over stuff with mohan and did not geta  reminder of the meeting
16:56:47 <maxamillion> nirik: do you mind updating the ticket?
16:57:02 <nirik> sure, just add that agreed and close it?
16:57:17 <maxamillion> nirik: +1
16:57:28 <maxamillion> #topic New Business
16:57:34 <maxamillion> #topic #1613 Deletion of EOL AMIs
16:57:34 <maxamillion> .fesco 1613
16:57:34 <maxamillion> https://fedorahosted.org/fesco/ticket/1613
16:57:35 <zodbot> maxamillion: #1613 (Deletion of EOL AMIs) – FESCo - https://fedorahosted.org/fesco/ticket/1613
16:57:55 <dgilmore> initially I removed the AMI's as soona  release went EOL
16:58:02 <dgilmore> and that made people upset
16:58:38 <maxamillion> I think it makes sense to remove them as soon as the release goes EOL
16:58:56 <jwb> why
16:59:10 <gholms> We don't do that for any other edition.
16:59:20 <jwb> we don't remove install media from our mirrors when it goes EOL.  AMIs seem equivalent there?
16:59:32 * nirik is ok with the release + last one
16:59:33 <maxamillion> jwb: yeah, that's fair
16:59:38 <jforbes> keeping AMIs shoudl cost no money at all, the account they are on is supposed to have free storage for our official AMIs (and not be used for anything else)
16:59:45 <dgilmore> so relased AMI's is currently on the AMI that was released at GA
17:00:10 <maxamillion> jforbes: is that the case currently though? I heard it was supposed to be but we were somehow paying for storage of images
17:00:13 <dgilmore> the ones built as part of the two wwek nightly compose are never really considered released and can be cleaned up at any point
17:00:15 <jforbes> That was the agreement I created when we first set those up, and why the fedora account exists as a separate entity
17:00:22 <gholms> jforbes: I'm under the impression that is no longer the case for reasons no one has been able to explain to me.
17:00:28 <dgilmore> jforbes: that was true in the past
17:00:30 <maxamillion> gholms: +1
17:00:31 <jforbes> maxamillion: I had not seen an update to those terms
17:00:41 * jsmith is happy to talk to David Duncan at Amazon if that's not the case
17:00:58 <dgilmore> there is ongoing discussions to have amazon cover the bill
17:01:01 <maxamillion> jsmith: this was discussed with him at Flock and I think he offered to work to resolve it
17:01:11 <maxamillion> or at least help
17:01:14 <dgilmore> which is currently a few thousand dollars a month
17:01:20 <jsmith> Yes, he did.
17:01:25 <maxamillion> yeah, last number I heard was like $5k/mo
17:01:27 <stickster> I can tell you we are charged for those, *but* jzb is working with AMZ folks to get that written off
17:01:31 <jforbes> dgilmore: well, that account was flagged when it was created, before we put the first image up. We were supposed to pay for machined time, not storage
17:01:34 <maxamillion> stickster: +1
17:01:40 <dgilmore> there is work going on to resolve the cost issue
17:01:44 <stickster> Not sure why that's taking a while, but dduncan is indeed involved and helping.
17:01:47 <jforbes> last months bill was just over $3k though, so something is up, I guess I can look at the itemized
17:01:48 <maxamillion> alright, so the billing issue is being resolved ... let's get back to the topic of the ticket
17:02:09 <dgilmore> jforbes: no idea when it changed, probably when we started using heaps of storage
17:02:39 <jforbes> Well, billing is an issue because amazon would prefer we don't delete images, and they were supposed to be footing the bill
17:02:51 <dgilmore> so there is only one set of GA AMI's per release
17:03:21 <stickster> jforbes: right, it causes issues for customers when we do
17:03:36 <dgilmore> ideally we make the compose process smarter and only make new images when something in them has changed
17:03:57 <dgilmore> and have a awesome super easy way for people to get the latest bits
17:04:14 <dgilmore> so they then do not go hardcoding AMI's into scripts
17:05:15 <gholms> If only cloudformation made things that easy.  :(
17:05:30 <dgilmore> gholms: but the cloud does all the things for you
17:05:37 <gholms> Heh
17:05:39 <dgilmore> and you never need to work about anything :P
17:06:36 <dgilmore> I wonder if we should not readress this after getting billing sorted
17:06:44 <jforbes> Okay, looking at the bill, we are being charged for storage, so that needs to be worked out, but some of it is being stored on ssds and various places. We probably need to address that
17:07:05 <dgilmore> because maybe without a cost to storage we do not care if there is 1000 new ami's a year
17:07:13 <jforbes> Machine time + data transfer, the bill should be less than a couple of hundred dollars
17:07:50 <dgilmore> though we are producing much more than 1000 a year
17:07:54 <Rathann> sorry guys, I need to go AFK, something urgent came up @home
17:08:10 <Rathann> I could be back in about 20 mins, not sure though
17:08:15 <jforbes> dgilmore: well, we don't want to abuse it either, so if we could limit it to new images only when there is something in the image which changes
17:08:38 <dgilmore> jforbes: we have no way to detect when things change today
17:08:52 <dgilmore> it is on the super long term nice to have roadmap
17:09:11 <nirik> Rathann: hope everything goes ok
17:09:28 <dgilmore> Rathann: what nirik said
17:09:36 <jforbes> I do know when the original agreement was made, the plan was to do images for each release and not update them, so we are using much more storage than they expected
17:10:05 <dgilmore> jforbes: right the cloudWG wants to have month updated ami's
17:10:16 <maxamillion> can we take the billing thing offline? because this isn't directly relevant to the ticket
17:10:18 <dgilmore> we could only upload once a week or something
17:10:27 <dgilmore> after some level of testing has passed
17:10:45 <jforbes> maxamillion: I would argue that it is relevant to the ticket, but we should differ the ticket until the billing is worked out
17:11:02 <maxamillion> fine
17:11:02 <dgilmore> jforbes: We need to stop putting full composes on the mirrors daily as well
17:11:23 <maxamillion> Proposal: Defer decision on Deletion of EOL AMIs until the AWS billing issue is sorted
17:11:29 <dgilmore> mirrors are not entirely happy about the size of daily churn
17:11:34 <dgilmore> maxamillion: +1
17:11:38 <maxamillion> +1
17:11:40 <paragan> maxamillion, +1
17:11:42 <nirik> sure, +1
17:12:33 <kalev> +1
17:12:57 <jsmith> +1
17:13:19 <maxamillion> jwb: sgallagh: ?
17:14:13 <jwb> sorry, on a call.  +0 because i didn't pay attention
17:14:39 <maxamillion> rgr
17:14:40 <sgallagh> +1
17:15:17 <maxamillion> #agreed defer decision on Deletion of EOL AMIs until the AWS billing issue is sorted (+1: 7, -1: 0, +0: 1)
17:15:25 <maxamillion> #topic #1614 FHS exception for /snap
17:15:25 <maxamillion> .fesco 1614
17:15:26 <maxamillion> https://fedorahosted.org/fesco/ticket/1614
17:15:27 <zodbot> maxamillion: #1614 (FHS exception for /snap) – FESCo - https://fedorahosted.org/fesco/ticket/1614
17:15:36 * Pharaoh_Atem sighs
17:15:52 <sgallagh> I made my opinion here known in the ticket
17:16:53 <nirik> yeah, I agree with sgallagh
17:16:57 * kalev did too.
17:17:00 <jwb> i have no overwhelming opinion.  allowing it on the grounds of interop seems reasonable.  rejecting because it's not in FHS seems like clinging to a spec everyone hates just to spite them
17:17:27 <jsmith> I agree with jwb
17:17:48 <jwb> i guess i would recommend waiting to see how the debian case plays out
17:18:06 <sgallagh> jwb: That would be reasonable except for the part where the other distros seem not to particularly want it there either
17:18:13 <maxamillion> yeah, I'm on board with waiting to see what debian does and how the arch bug plays out
17:18:26 <Pharaoh_Atem> do we have any contacts with debian?
17:18:30 <jwb> sgallagh: right.  hence waiting for debian.  or reaching out to debian
17:18:46 <Pharaoh_Atem> as the reviewer, I tried to find info on the debian decision, but I can't find any
17:18:56 <maxamillion> I don't want to make a hard/fast call on anything that would make us an outlier among other community distros
17:20:10 <Pharaoh_Atem> I'd like to get the snapd package in sooner rather than later if this could be resolved, so I'm hoping someone here has some friends "high up"
17:20:13 <dgilmore> I think there is value in being the same across all distros
17:20:13 <Pharaoh_Atem> in Debian
17:20:18 <maxamillion> dgilmore: +1
17:20:31 <maxamillion> does anyone know someone who's a core dev of debian they could reach out to? or involved with arch?
17:20:56 <Pharaoh_Atem> I have a colleague involved in Arch, and I think they're kind of waiting on us
17:21:13 <Pharaoh_Atem> my colleague is the one that triggered the bug
17:21:48 <Pharaoh_Atem> the comments in the bug (https://bugs.archlinux.org/task/50435) are interesting though
17:21:49 <maxamillion> Pharaoh_Atem: ah ok, any chance they can chime in on the ticket? I'd like to have an open dialog with members of the other distros in order to come to a joint consensus (if we can)
17:22:09 <Pharaoh_Atem> I can certainly try
17:22:14 <maxamillion> also, we should reach out to some of the openSUSE folks as well
17:22:22 <Pharaoh_Atem> yeah, definitely
17:22:39 <kalev> I'm rather for waiting, don't think there's much rush in getting this in quickly
17:22:57 <dgilmore> kalev: indeed
17:23:06 <maxamillion> cwickert is involved with openSUSE these days iirc, so he's likely a good point of contact to start the discussion
17:23:12 <dgilmore> I would rather do it once and right than redo it a few times
17:23:15 <Pharaoh_Atem> our friends in openSUSE are a bit further along than we are, it seems: https://build.opensuse.org/search?utf8=%E2%9C%93&search_text=snapd&commit=Submit&issue_tracker=bnc&issue=&project=0&project=1&package=0&package=1&name=0&name=1&title=0&description=0&attrib_type_id=
17:23:19 <Pharaoh_Atem> ugh
17:23:24 <Pharaoh_Atem> https://build.opensuse.org/package/show/system:snappy/golang-github-snapcore-snapd
17:23:31 <Pharaoh_Atem> they've got it in a devel project now
17:23:48 <Pharaoh_Atem> though the builds appear to be broken
17:23:58 <dgilmore> Pharaoh_Atem: I do not think that is part of OpenSuSE
17:24:05 <maxamillion> Pharaoh_Atem: those look like user baked builds and not part of the core distro ... unless I'm mistaken on the OBS labels
17:24:13 <sgallagh> That looks like the equivalent of COPRs
17:24:14 <Pharaoh_Atem> you might be right
17:24:32 <Pharaoh_Atem> I get confused with how these projects work in OBS sometimes
17:24:40 <maxamillion> wait, this one might be system:snappy https://build.opensuse.org/project/show/system:snappy
17:25:26 <maxamillion> alright, lets get people with action items to reach out to various contacts ... I'll reach out to cwickert from OpenSUSE and paultag from Debian to see where to go from here
17:25:37 <sgallagh> maxamillion++
17:25:37 <zodbot> sgallagh: Karma for maxamillion changed to 9 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:25:42 <Pharaoh_Atem> awesome
17:26:02 <Pharaoh_Atem> actually
17:26:05 <Pharaoh_Atem> I think pid1 is here
17:26:09 <maxamillion> Pharaoh_Atem: you will reach out to your arch contact?
17:26:13 <Pharaoh_Atem> he's the Arch guy
17:26:15 <maxamillion> ah
17:26:18 <maxamillion> pid1: hello :)
17:26:19 <Pharaoh_Atem> I asked him to hang out here for the meeting now
17:27:10 <Pharaoh_Atem> he's also the one that filed the bug in Arch
17:27:51 <maxamillion> Pharaoh_Atem: would you mind taking the action item to follow up with him off-meeting?
17:27:51 <pid1> o/
17:27:54 <maxamillion> oh
17:28:04 <Pharaoh_Atem> here he is :)
17:28:24 <maxamillion> pid1: would you mind if I followed up with you off-meeting about the /snap topic?
17:28:31 <pid1> maxamillion: not at all
17:28:35 <maxamillion> pid1: awesome
17:28:41 <Pharaoh_Atem> yay friends :D
17:28:46 <pid1> Timothy doesn't consider it an issue since we're only creating /snaps at runtime
17:28:54 <Pharaoh_Atem> maxamillion++
17:28:57 <pid1> I don't personally see how that really makes a difference here, though.
17:29:12 <Pharaoh_Atem> that was the argument zyga made to me
17:29:42 <pid1> We're seemingly just deferring to "Upstream expects /snaps, so it will exist."
17:29:48 <maxamillion> pid1: well, we mostly want to try and collaborate with all community distros about the direction we take instead of making an uninformed or premature decision that could leave us as an outlier
17:29:52 <pid1> Considering how much Arch defers to upstream behavior, I'm not entirely surprised.
17:29:57 <maxamillion> pid1: fair
17:30:00 <sgallagh> Honestly, that bothers me more. Not only is it a non-standard location, but it's a non-standard location that packaging tools don't own and manage...
17:30:22 <Pharaoh_Atem> my concern with it is that upstream is essentially defying its own distro rules for this
17:30:31 <maxamillion> sgallagh: yeah, the "packaging tools don't own and manage" bit concerns me
17:30:34 <maxamillion> alright
17:30:58 <pid1> If we are going to create it at all, I'd rather /snaps be created by the package so it is owned and managed.
17:31:02 * jsmith has to go.... sorry
17:31:13 <pid1> oh, sgallagh ++
17:31:15 <maxamillion> #action maxamillion to reach out to openSUSE, arch, and debian contacts on /snap topic to aid in cross-distro agreement on approach
17:31:17 <Pharaoh_Atem> at least if we allow it, we can have the rpm spec create and own /snap
17:31:18 <pid1> Same thoughts here.
17:31:29 <pid1> Pharaoh_Atem: Same thoughts with pacman.
17:31:38 <maxamillion> Proposal: defer FHS exception for /snap until next week's meeting
17:31:49 * dgilmore does not know enough about how snaps are created to say
17:32:00 <Pharaoh_Atem> snaps are unaware of where they exist on the filesystem
17:32:13 <Pharaoh_Atem> they use internal environment variables to determine their FS structure
17:32:13 <dgilmore> but given how flatpak is and that it needs a rebuild to work, I wonder if snaps will be in the same boat
17:32:44 <Pharaoh_Atem> they use a combination of seccomp, chroot, bind mounts, and mandatory access control to jail the environment
17:32:55 <maxamillion> there's a proposal up, can FESCo members please vote or suggest something else?
17:32:56 * Rathann is back
17:32:58 <Pharaoh_Atem> the snaps inside have a faked FHS structure
17:33:02 <maxamillion> Proposal: defer FHS exception for /snap until next week's meeting
17:33:10 <dgilmore> maxamillion: +1
17:33:12 <maxamillion> +1
17:33:12 <paragan> +1
17:33:14 <nirik> +1
17:33:26 <dgilmore> I think we need more info on how it all is supposed to work
17:33:28 <Rathann> +1
17:33:31 <sgallagh> +1 for now, I guess
17:33:39 <jwb> +1
17:33:52 <Pharaoh_Atem> a cross-distro agreement will allow us to be united when we come back with a decision, one way or another
17:33:57 <maxamillion> alright, we lost jsmith ... did we lose anyone else in the vote pool?
17:34:01 <Pharaoh_Atem> so I'm godd with a deferral
17:34:05 <Pharaoh_Atem> *good
17:35:00 <sgallagh> Pharaoh_Atem: Thinking a little high of yourself? ;-)
17:35:06 <Pharaoh_Atem> haha
17:35:31 <maxamillion> kalev: you still with us?
17:35:52 <kalev> sorry, +1
17:35:57 * kalev was filing expense reports.
17:36:03 <Pharaoh_Atem> blech :)
17:36:08 <maxamillion> #agreed defer FHS exception for /snap until next week's meeting (+1: 8, -1: 0, +0: 0)
17:36:21 <maxamillion> #topic Next week's chair
17:36:27 <paragan> maxamillion, we have 2 tickets more 1612 and 1615
17:36:43 <jwb> i can't chair.  have another call booked in the middle of this meeting
17:36:43 <maxamillion> paragan: not in the agenda that got sent out ... did they show up today?
17:36:50 <maxamillion> #undo
17:36:50 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x268438d0>
17:37:06 <jwb> maxamillion: people emailed to the devel list and asked to add them like the agenda says to :)
17:37:11 <paragan> maxamillion, not on agenda though requested on list
17:37:15 <jwb> actually 3
17:37:18 <maxamillion> bleh, I missed it
17:37:20 <maxamillion> *sigh*
17:37:28 <maxamillion> this meeting just won't end
17:37:39 <jwb> oh, 2
17:37:43 <maxamillion> <3 all of you but I'm hungry :D
17:37:47 <jwb> heh
17:38:00 <sgallagh> The Wayland one at least can't wait, I think
17:38:06 <paragan> both are easy tickets and need just voting I guess
17:38:10 <jwb> i'd suggest we start with https://fedorahosted.org/fesco/ticket/1612
17:38:11 <maxamillion> #topic #1615 Consider Wayland by default for F25
17:38:15 <maxamillion> .fesco 1615
17:38:16 <zodbot> maxamillion: #1615 (Consider Wayland by default for F25) – FESCo - https://fedorahosted.org/fesco/ticket/1615
17:38:19 <maxamillion> https://fedorahosted.org/fesco/ticket/1615
17:38:23 <jwb> or that
17:38:30 <maxamillion> jwb: sorry, I went in order of requests to the mailing list thread
17:38:44 <jwb> no worries
17:39:15 <nirik> so, is wayland set to be default already in f25? I'd guess so since rawhide was changed before branching...
17:39:21 <sgallagh> Yes
17:39:36 <sgallagh> It was planned that way since F24, but no one rememebered to actually file a Change proposal
17:39:44 <maxamillion> sgallagh: fun :)
17:39:45 <nirik> yeah. ;(
17:39:47 <paragan> yes its default in f25
17:39:49 <Pharaoh_Atem> :/
17:39:57 <sgallagh> The question before us is whether we want to leave it that way or revert to X.
17:40:03 <maxamillion> well I guess technically there was the Change proposal from F24, it just wasn't updated and resbumitted
17:40:18 <sgallagh> This is pretty much a judgement call; we need to do it sooner or later. It's going to have breakage whenever it happens.
17:40:24 <maxamillion> sgallagh: +1
17:40:35 <nirik> well, I'd defer in this area to the workstation WG. If they wish to wayland default, then thats fine with me.
17:40:52 <sgallagh> They deferred to us :)
17:40:57 <maxamillion> I'm game, let's push the leading edge ... we did it with GNOME3 and systemd and I'm sure this won't be the last time something like this comes up
17:41:11 <dgilmore> what nirik said, I have not tried wayland at all and have no idea on how well it works or doesnt
17:41:20 <sgallagh> Not necessarily the best examples... but probably accurate ones.
17:41:29 <nirik> For the most part it's quite functional. But there's bugs, corner cases and just plain differences.
17:41:37 <sgallagh> I've been using it for a year. There's one or two rough edges, but it's mostly been good for me
17:41:41 <nirik> but yeah, +1 for the change
17:41:47 <sgallagh> So formal proposal:
17:41:47 <maxamillion> sgallagh: right, I selected those examples on purpose because they were rocky and we handled them pretty well :)
17:42:18 <sgallagh> Proposal: FESCo agrees to go ahead with Wayland by default provided that release notes and common bugs are clear about how to switch back to X11 if needed.
17:42:28 <Pharaoh_Atem> afaik, biggest pain point is a11y still busted for Wayland
17:42:28 <nirik> sure. +1
17:42:32 <Pharaoh_Atem> but I think everyone knows that already
17:42:39 <maxamillion> sgallagh: +1
17:42:41 <sgallagh> +1
17:42:58 <jforbes> And nvidia driver users, but discussions have been happening upstream, so hopefully those will be resolved
17:43:04 <paragan> sgallagh, +1
17:43:18 <dgilmore> sgallagh: +1
17:43:27 <Rathann> sgallagh: +1
17:43:28 <jwb> i find this discussion bizarre
17:43:31 <jwb> but +1
17:43:32 <kalev> +1, we'll also discuss it at next Workstation meeting and may go back to xorg depending on how it looks at that point
17:43:40 <sgallagh> jwb: What about it?
17:44:23 * nirik somewhat does too, but whatever works
17:44:25 <jwb> sgallagh: because we were debating on-list about a ca-cert change VERY SERIOUSLY but we're very flippant about possibly pissing off a significant portion of our user base with Wayland
17:44:33 <maxamillion> we're short one vote, who we missing?
17:44:44 <Pharaoh_Atem> jsmith is away, I think
17:45:00 <dgilmore> jsmith and Rathann have left
17:45:02 <maxamillion> yeah, but we had 9 and jsmith left and we have 7 votes counted
17:45:07 <Rathann> dgilmore: no, I'm back
17:45:09 <maxamillion> dgilmore: Rathann is back and voted
17:45:11 <sgallagh> jwb: That is an interesting point. I gues there's a bit of cognitive dissonance there, huh?
17:45:13 <dgilmore> ahh okay :)
17:45:28 <Pharaoh_Atem> jwb: bcuz security :P
17:45:35 <jwb> sgallagh: yes, that's exactly the term i was trying to remember
17:45:55 <Rathann> well I'm +1 to disabling legacy CAs by default
17:46:00 <sgallagh> The difference (rationalization?) in my mind is that it's already been that way through Rawhide and we've been talking about it for years.
17:46:02 <Rathann> there's been enough time already
17:46:07 <sgallagh> Whereas the CA thing just kind of appeared.
17:46:22 <sgallagh> (And I'm still fine with including it, I just don't want to rock the boat during Alpha)
17:46:26 <maxamillion> #agreed FESCo agrees to go ahead with Wayland by default provided that release notes and common bugs are clear about how to switch back to X11 if needed. (+1: 7, -1: 0, +0: 0)
17:46:31 <dgilmore> the CA thing has ben there for years, just not as in your face
17:47:54 <maxamillion> #topic #1612 Provenpackager request jforbes
17:47:59 <maxamillion> .fesco 1612
17:48:00 <zodbot> maxamillion: #1612 (Provenpackager request jforbes) – FESCo - https://fedorahosted.org/fesco/ticket/1612
17:48:05 <maxamillion> https://fedorahosted.org/fesco/ticket/1612
17:48:15 <dgilmore> I think there is anough +1's in the ticket
17:48:28 <sgallagh> /me agrees
17:48:47 <maxamillion> +1
17:48:48 <dgilmore> though Rathann gave a -1
17:48:57 <dgilmore> which is why it is here
17:48:59 <jwb> dgilmore: which means it goes to a vote by FESCo
17:49:07 <jwb> and every other fesco member said +1
17:49:19 <dgilmore> I am +1 to jforbes being proven packager
17:49:26 <jwb> which means he'd be on the losing side of the vote unless someone else changed their mind
17:49:30 <dgilmore> honestly kinda surprissed he is not already
17:49:35 <jwb> so was he
17:49:46 <maxamillion> Proposal: Approve jforbes Provenpackager request
17:49:48 <maxamillion> +1
17:49:50 <dgilmore> +1
17:49:53 <sgallagh> +1
17:50:20 <paragan> +1
17:50:31 <jwb> +1
17:50:43 <Rathann> I'm still -1 for the reasons already stated
17:51:13 <maxamillion> Rathann: was there any response or further discussion you'd like to have based on the response in the ticket?
17:51:38 <Rathann> well if he did a couple of package reviews, I'd be happy to change my vote
17:51:53 <sgallagh> Rathann: Well, he's not applying for Sponsor
17:51:59 * jforbes is here and happy to answer any questions
17:52:29 <tibbs> I forget if we have actual guidelines for uberpackager.
17:52:29 <jwb> the vote as it stands is enough to approve
17:52:46 <tibbs> I'm not generally involved in that side of things, so I know I didn't write any.
17:52:54 <tibbs> But if there aren't, then there certainly should be.
17:53:05 <Pharaoh_Atem> well, it's the reason I've never applied to be one
17:53:12 <Pharaoh_Atem> I have no idea what the criteria for it is
17:53:15 <nirik> yes, there are
17:53:19 <nirik> https://fedoraproject.org/wiki/Provenpackager_policy
17:53:21 <paragan> there is
17:53:59 <jforbes> Rathann: I am not against doing package reviews, and have done a couple over the years, but I am rarely have a ton of free time to go looking for more things since just the kernel queue is several hundred deep at any given time
17:54:07 <nirik> reviews shouldnt be a critera. Thats why we split sponsors and provenpackagers. ;)
17:54:37 <jwb> personally, provenpackager to me signifies a level of trust in the person.
17:54:47 <tibbs> That says what they do, not really the criteria for applying.
17:54:52 <Rathann> jforbes: if you have, I couldn't find them :(
17:55:08 <jforbes> Rathann: it has been a few years
17:55:09 <jwb> Rathann: it's because they were done at the beginning of Fedora.
17:55:15 <tibbs> sponsor has discrete guidelines for package reviews, packages maintained and packager group membership time.
17:55:25 <tibbs> Just saying, not to derail, but that would be useful to have.
17:56:16 <Rathann> I'm just saying it's good to do a review once in a while if only to refresh your knowledge of the FPG
17:56:24 <Rathann> because they get updated
17:56:41 <Rathann> and since jforbes hasn't done any in years
17:56:43 <nirik> I suppose. I'll note also tho that when we closed things to all packagers we expected provenpackager to have a somewhat low bar... been around, won't break guidelines, asks for help, etc.
17:57:00 <tibbs> Kick me out now, because I haven't had time to do a review in ages.
17:57:04 <jwb> and i'm contending that knowledge of the FPG is good, but is not necessary since provenpackager is useful for fixing problems that have nothing to do with packaging.
17:57:10 <jforbes> The real thing that spurred this request though was pesign needing a build last friday evening, and the number of provenpackagers who can also do signed builds is maybe 2, neither of which were around
17:57:30 <Rathann> jforbes: sure, that's a valid argument
17:57:31 <jforbes> Rathann: FPG changes are posted to the list and reviewed
17:57:49 * pjones definitely thinks jforbes should have provenpackager
17:57:50 <jforbes> I don't ignore them just because I am not reviewing other people's packages actively
17:58:06 <jwb> nirik: right.  again, provenpackager is a measure of trust.  it is not some kind of test of FPG knowledge
17:58:17 * nirik nods
17:58:31 <maxamillion> NOTE: in case anyone forgot there is a vote up and we're still short FESCo member votes
17:58:37 <Rathann> sure, but one needs some basis for that trust
17:58:43 <dgilmore> jforbes: and the list of people who can do signed builds is about 5 maybe 6
17:58:52 <jwb> maxamillion: we short on members voting, but we are not short on enough votes to pass approval
17:58:52 * nirik is +1 as voted in ticket also
17:59:10 <sgallagh> maxamillion: More than five FESCo members +1ed in the ticket as well
17:59:27 <dgilmore> given that the trust of doing signed builds is much higher than the trust of provenpackager, perhaps if you can do signed builds proven packager comes with it
17:59:28 <jwb> Rathann: put succinctly, if you don't trust jforbes then you should be running a different distribution.
17:59:37 <jwb> Rathann: he literally builds your kernel
17:59:38 <maxamillion> sgallagh: yeah
17:59:53 <pjones> Rathann: he's been maintaining our kernel packages for years, he's run for fesco and had a fairly strong showing in the results several times...
17:59:55 <sgallagh> jwb++
17:59:55 <zodbot> sgallagh: Karma for jwboyer changed to 5 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:00:04 <Rathann> oh I trust him to take care of the kernel alright
18:00:17 <maxamillion> #agreed Approve jforbes Provenpackager request (+1: 7, -1: 1, +0: 0)
18:00:34 <jforbes> Rathann: the FC1 x86_64 offical ISOs were built on my home systems because the Fedora buildsystems couldn't spit them out, the first AMIs were as well.
18:00:41 <Pharaoh_Atem> wow
18:00:50 <jwb> ok, now we can move on to chair
18:00:55 <jwb> which i still can't do :\
18:01:02 <jforbes> I think I have done a few things to earn the community trust
18:01:13 <Pharaoh_Atem> FC1 was near the beginning of my Linux journey
18:01:26 <maxamillion> #topic Next week's chair
18:01:40 <nirik> If no one else can I guess I can...
18:01:59 <dgilmore> I can
18:02:03 <dgilmore> it has been awhile
18:02:13 <Rathann> nirik: I was going to say the same ;)
18:02:47 <maxamillion> #info dgilmore to chair next weeks meeting
18:03:00 <maxamillion> #topic Open Floor
18:04:19 <jwb> Proposal: end meeting before maxamillion goes into low-blood sugar coma
18:04:22 <dgilmore> I have nothing but burritos for you
18:04:28 <maxamillion> lol
18:04:34 <pjones> tacos are pretty good too
18:04:37 <Pharaoh_Atem> mac'n'chz
18:04:42 <maxamillion> I'll give it another minute just to be sure
18:04:52 <Pharaoh_Atem> and chicken nuggets :)
18:04:58 <gholms> hotdogs, anyone?
18:04:59 <jforbes> Dunno, tacos and burritos might be hard to find near you maxamillion
18:04:59 <dgilmore> pjones: tacos are pretty good
18:05:02 <sgallagh> Hang on, what about the CA cert thing?
18:05:14 <jwb> sgallagh: doing it as an update seems fine
18:05:23 <jwb> sgallagh: and kai seemed agreeable tot hat
18:05:42 <sgallagh> Yeah, I think that's the best course of action.
18:05:46 <maxamillion> jforbes: lol?
18:05:54 <sgallagh> Do we care enough to vote or just say "go ahead"?
18:06:08 <maxamillion> alright, thanks everyone for attending and participating!
18:06:09 <maxamillion> #endmeeting