18:00:03 <nirik> #startmeeting FESCO (2015-05-27)
18:00:03 <zodbot> Meeting started Wed May 27 18:00:03 2015 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:03 <nirik> #meetingname fesco
18:00:03 <zodbot> The meeting name has been set to 'fesco'
18:00:04 <nirik> #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh
18:00:04 <nirik> #topic init process
18:00:04 <zodbot> Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza
18:00:15 <sgallagh> .hello sgallagh
18:00:16 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:01:07 <nirik> well perhaps we won't have quorum. ;)
18:01:17 <jwb> i'm kind of here.  not feeling well
18:01:21 <ajax> hi
18:01:23 <thozza> hi all
18:01:25 <nirik> :( sorry to hear it jwb
18:01:49 <paragan> Hi
18:01:54 <apatel> Hi
18:02:12 <jkurik> hi there
18:02:18 * rishi is here
18:02:19 <nirik> ok, so I guess we do have quorum. :) lets go ahead then...
18:02:26 <nirik> #topic #1441	Packaging: Practices for Migration of cron jobs to systemd timer units
18:02:26 <nirik> .fesco 1441
18:02:26 <nirik> .fesco 1446
18:02:28 <zodbot> nirik: #1441 (Packaging: Practices for Migration of cron jobs to systemd timer units) – FESCo - https://fedorahosted.org/fesco/ticket/1441
18:02:31 <zodbot> nirik: #1446 (packaging guidelines - default-on services vs. "public network socket") – FESCo - https://fedorahosted.org/fesco/ticket/1446
18:02:54 <nirik> there's two tickets here, but I guess it's clarification needed really.
18:03:30 <sgallagh> Right, I may have misinterpreted the original meaning and clarified incorrectly (or at least inconsistently)
18:04:01 <sgallagh> The main question here is whether we require FESCo approval for a service to autostart if it only listens on localhost TCP
18:04:22 <ajax> i don't see a reason to treat that differently from a unix socket really
18:04:23 <sgallagh> I personally don't see a meaningful distinction between localhost and UNIX sockets
18:04:25 <dgilmore> hi all
18:04:54 <sgallagh> ajax: There are a small number of differences: UNIX sockets can be protected with UNIX permissions
18:05:04 <sgallagh> I think they can both be constrained by SELinux though
18:05:13 <ajax> sgallagh: sure, and tcp sockets actually obey network namespaces and unix sockets don't
18:05:20 <sgallagh> /me nods
18:05:27 <nirik> what is/was the existing policy.
18:05:29 * nirik reads up
18:05:41 <thozza> I think the policy states that if the service is listening on a socket it may not be enabled by default without approval
18:05:47 <sgallagh> "If a service does not require configuration to be functional and does not listen on a network socket"
18:06:04 <sgallagh> where I added "public" before "network socket"
18:06:09 <nirik> yeah, doesn't really define "network socket"
18:06:42 <drago01> well its a pretty much defined term
18:06:42 <thozza> ahh, ok... now I see the problem
18:07:04 <drago01> does not mean that whoever wrote that meant local as well or not though
18:07:32 <sgallagh> drago01: Right, which is why I attempted to remove the ambiguity as to how I interpreted it (and how it has realistically been treated up to now)
18:07:51 <drago01> sgallagh: *nod*
18:08:25 <jwb> this sounds tedious.  next week we'll get into a discussion on what local means in light of containers, etc
18:08:40 <dgilmore> jwb: indeed
18:09:16 <drago01> just add "common sense is required to understand this document"
18:09:17 <drago01> ...
18:09:17 <sgallagh> jwb: Well, if we can agree that the intent is that "services that are accessible from a different physical machine" may not auto-start, we can phrase that appropriately.
18:09:25 <sgallagh> s/physical/physical or virtual/
18:09:30 <rishi> Are there are real examples of services that only use a localhost socket? Just curious.
18:09:39 <nirik> postgresql by default?
18:09:40 <sgallagh> rishi: tog-pegasus by default
18:09:43 <ajax> local dns cache i imagine
18:09:43 <drago01> database  servers?
18:09:44 <zbyszek> rishi: elasticsearch
18:09:48 <nirik> unbound yeah
18:09:54 <sgallagh> So... yes :)
18:10:03 <dgilmore> rishi: by default sendmail and postfix
18:10:19 <thozza> rishi: DNS resolvers in general
18:10:23 <thozza> in Fedora
18:10:23 <drago01> ajax: does X listen on tcp by default?
18:10:24 <rishi> Right.
18:10:48 <zbyszek> drago01: by default default yes, but it's been run with -nolistentcp for ages
18:10:50 <jwb> i'd rather just require "if you use a socket, you must get approval to auto-start"
18:11:06 * nirik was busy with release and hasn't had too much time to ponder on this. I don't know that it's something we can't adjust moving forward either
18:11:08 <drago01> zbyszek: ah ok
18:11:18 <sgallagh> Proposal: Rephrase this line as "If a service does not require configuration to be functional and does not listen on a network socket for connections originating on a separate physical or virtual machine"
18:11:27 <thozza> jwb: some service may use the local socket just for runtime configuration
18:11:32 <jwb> i don't care
18:11:35 <sgallagh> jwb: That would be extremely tedious.
18:11:55 <jwb> i'm -1 to the proposal.  vote away
18:12:42 * jwb notes that nobody is actually going to be checking for this in terms of enforcement anyway
18:12:43 <rishi> sgallagh: Yes, +1. Sounds sane to me.
18:12:53 <ajax> sgallagh: +1
18:13:26 * nirik would be fine with that, but also jwb's more restrictive one. We can always adjust if we get too many requests or figure out if they fit in some new category.
18:13:28 <sgallagh> jwb: I believe that the security team runs semi-regular portscans of Fedora to keep an eye on this stuff
18:13:33 <thozza> sgallagh: by "separate" you mean not running locally? e.g. VM
18:13:41 <thozza> or what it means? :)
18:13:55 <sgallagh> thozza: A VM running locally is functionally a separate entity as far as I am concerned.
18:14:28 <thozza> right, we should just make sure everyone thinks that
18:14:32 <thozza> ;)
18:14:47 <rishi> thozza: It says "separate physical or virtual machine".
18:14:56 <sgallagh> thozza: I'm not going to get so pedantic that we start defining the word "the"...
18:14:57 <rishi> That should be clear enough.
18:15:36 <thozza> it's clear enough for me, but was already before ;)
18:15:41 <nirik> so thats +4/-1 I guess? (counting me as +1, and sgallagh +1 to his own proposal).
18:15:48 <thozza> sgallagh: +1
18:15:51 <sgallagh> Yes, +1 to my own proposal
18:15:55 <thozza> I'm not against the clarification
18:16:35 <nirik> dgilmore: ? anyone else not vote?
18:16:45 <thozza> nirik: I just did ;)
18:16:50 <dgilmore> I have no real opinion right now
18:16:58 <dgilmore> not had enough time to take it all in
18:17:22 <nirik> #agreed Rephrase this line as "If a service does not require configuration to be functional and does not listen on a network socket for connections originating on a separate physical or virtual machine" (+5,-1,1)
18:17:29 <nirik> #topic #1444 updates deliverables
18:17:30 <nirik> .fesco 1444
18:17:31 <zodbot> nirik: #1444 (updates deliverables) – FESCo - https://fedorahosted.org/fesco/ticket/1444
18:17:36 <nirik> dgilmore: you want to talk about this?
18:17:41 <dgilmore> nirik: sure
18:18:26 <dgilmore> along the vein of defining what we are going to ship as part of a release
18:18:58 <dgilmore> there is a desire for more to be part of the updates process than just a repo of rpms
18:19:52 <dgilmore> knowing before a release what things are expected of updates, and if they are every updates push or some time or specific update based criteria for triggering them to be made
18:20:04 <dgilmore> some concrete examples we have today
18:20:09 <dgilmore> the atomic installer
18:20:23 <paragan> does this ticket mean we are planning to release updated iso for released Fedora versions?
18:20:24 <dgilmore> the change owners want the nstaller iso to be regullary updated
18:20:48 <dgilmore> so that when you do an install you do not have to update the install post install as you already have the current update
18:20:48 <jwb> paragan, no, not really
18:21:06 <jwb> paragan, only for some subset of things (like the atomic example dgilmore is talking about)
18:21:21 <dgilmore> paragan: depends on what you define as updates iso
18:21:39 <dgilmore> installer I do not xpect updates
18:21:42 <dgilmore> expect
18:21:57 <dgilmore> but docker base image, potentially layered images,
18:22:02 <dgilmore> cloud images
18:22:10 <dgilmore> atomic pieces
18:22:33 <rishi> jwb: One might potentially want the workstation ISOs to be updated?
18:22:49 <paragan> okay
18:22:51 <dgilmore> So my request is to ensure that along with defining what we ship with the release we define what is to be updated
18:23:04 <dgilmore> rishi: right, updated live images maybe
18:23:09 <nirik> so, aside releng time and disk space, etc, there's the matter of QA on these.
18:23:13 <jwb> rishi, it's a possibility.  how realistic it is, i have no idea.  frankly, i don't think it is, but that is why were talking about this :)
18:23:20 <dgilmore> rishi: i think the only thing no one has ever wanted is updated installer images
18:23:39 <nirik> dgilmore: which may be because anaconda seldom/never updates after release.
18:23:40 <dgilmore> nirik: right
18:23:48 <jwb> dgilmore, lots of people have wanted updated installer images
18:24:01 <dgilmore> nirik: I guess also do we tightly couple with updates pushes or do them seperate also
18:24:09 <sgallagh> Which is also to the good: if we disallow anaconda updates post-release, the vast majority of release validation tests will remain the same
18:24:12 <dgilmore> jwb: okay, I have never been asked
18:24:19 <nirik> jwb: yeah, like that Linus Torvalds guy a while back. ;)
18:24:23 <sgallagh> (If we wanted to do these updated releases)
18:24:31 <jwb> dgilmore, that's because fedora unity has been providing them for a long time.  whether they still do, i don't know
18:24:40 <dgilmore> jwb: only lives
18:24:48 <nirik> jwb: Southern_Gentlem does lives.
18:25:22 <jwb> sgallagh, i don't think that follows
18:25:40 <jwb> but we're arguing about a specific case.  the general idea in this ticket is good
18:25:42 <sgallagh> jwb: Sorry, I phrased that poorly.
18:25:47 <nirik> sgallagh: problem is the shifting sands of tools anaconda uses.
18:26:19 <dgilmore> specifics I imagine would be sorted out while working out if we accept a change or not
18:26:49 <dgilmore> as in the change would say we want to have updated versions of our deliverable during the life of the release
18:26:57 <Southern_Gentlem> yes the anaconda no changes accept at for releases has benn a long running issue
18:26:57 <rishi> The big attraction of a respun workstation ISO would be fixes to installation path bugs.
18:27:41 <rishi> If that is not going to happen, then it is mostly "reduce amount of updates to download after release" versus "reduced quality due to lack of QA".
18:27:53 <nirik> dgilmore: as part of a deliverables matrix, yeah... so it would say: "this is the input" "This is the exact output thing" "yes, we want updated thing when X happens"
18:28:00 <rishi> And at that point, it is probably not worth the trouble.
18:28:08 <jwb> i think once you start (frequently) updating any and every possible image, you really start to blur the lines of what a "release" means and move towards more of a rolling release style
18:28:12 * rishi is speaking from the workstation point of view
18:28:25 <drago01> call it F22.1 F22.2 etc
18:28:34 <dgilmore> nirik: right.
18:28:53 <nirik> jwb: yeah, that too indeed.
18:29:09 <dgilmore> jwb: indeed, some newer techs do not fit into the old distribution method
18:29:27 <Southern_Gentlem> rishi i will continue doing updated lives which takes care of that as well for new installs
18:29:27 <rishi> jwb: nirik: I don't think it blurs the importance of a "release".
18:29:34 <dgilmore> and things like updated docker base images and cloud images are kinda necessary
18:29:37 <jwb> maybe the old distribution method isn't valid any longer
18:29:40 <dgilmore> more so docker than cloud
18:29:48 <dgilmore> jwb: perhaps
18:29:49 <jkurik> this looks like a similar concept we are going to implement for RHEL7 (starting with Docker images)
18:29:59 <rishi> How this whole thing affects QA is my big concern.
18:30:12 <rishi> QA resources, to be precise.
18:30:13 <dgilmore> I am just trying to set expections clearly for what releng will be doing
18:30:14 <jwb> rishi, yes.  qa needs to weigh in here
18:30:34 <dgilmore> but it does heavily effect QA also
18:30:37 <drago01> rishi: test automation would help not sure how far things are there though
18:30:53 <nirik> right.
18:31:09 <rishi> drago01: People keep saying "test automation", yet we keep seeing stable Fedora updates cause regressions.
18:31:19 <nirik> so, actions here? ping qa folks about it? should we start a discussion on devel? or wait until we have more concrete proposals?
18:31:37 <jwb> nirik, a combination of the first 2
18:31:46 <dgilmore> nirik: I think we need to be fairly agressive in working things out
18:31:57 <dgilmore> so reach out to QA and start a discussion on devel
18:32:00 <rishi> We should have been gating updates and batching them long ago, but that battle is lost.
18:32:11 <nirik> it would also help here to have deliverables worked out or at least somewhat worked out
18:32:17 <drago01> rishi: might be because we do *not* have test automation yet?
18:32:21 <drago01> or what's your point?
18:32:23 <jwb> also, one possibly solution is very much "if you want updated images, please tell us which people are volunteering to QA those"
18:32:32 <rishi> nirik: I would say ping QA first. It is basically QA and rel-eng who will bear the brunt of this.
18:32:47 <nirik> jwb: yeah, but I am somewhat leary of that unless we also say "and if they don't we won't release the images"
18:33:03 <jwb> nirik, the implication is heavily present, yes.  we can make it clear
18:33:06 <nirik> dgilmore: can you start a discussion on the qa list?
18:33:25 <drago01> its kind of lame that you install fedora a few months after relase and have to download a few tb of updates
18:33:26 <rishi> drago01: My point is whatever test automation we have is not robust enough.
18:33:36 <dgilmore> jwb: yeah, a lot of teh requests are coming from the cloud wg, I think they need to get more people signed up to do qa, and we need a way to sign off on updates deliverables
18:33:46 <dgilmore> nirik: sure. I can
18:33:52 <nirik> rishi: we don't really have any. ;) But people are working on it... it might happen someday. ;)
18:33:58 <jwb> drago01, hyperbole much?
18:34:12 <drago01> jwb: the "t" yes otherwise no
18:34:22 <rishi> nirik: Yes, I know. I don't want to disparage the Taskotron guys.
18:34:27 <rishi> Sorry if it came out that way.
18:34:28 <nirik> #action dgilmore to open discussion on the qa/test list about testig updated deliverables.
18:34:32 <jwb> drago01, right.  the problem is bad.  let's not make it intractable
18:34:41 <drago01> jwb: ok fair enough
18:35:11 <nirik> shall we keep the ticket open and discuss feedback from qa next time?
18:35:15 <jwb> sure
18:35:18 <dgilmore> sure
18:35:41 <paragan> yes
18:35:45 <sgallagh> ok
18:35:49 <rishi> +1
18:36:00 <nirik> #info will keep ticket open and discuss qa folks feedback next time
18:36:11 <nirik> #topic #1445 F23 Self Contained Changes
18:36:12 <nirik> .fesco 1445
18:36:13 <zodbot> nirik: #1445 (F23 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1445
18:36:36 <thozza> +1
18:36:39 <jkurik> We have two requests for new Spins
18:36:47 <jkurik> Cinnamon look fine for me
18:36:57 <jkurik> I am a bit unsure regarding the Netizen
18:37:04 <dgilmore> +1 to cinnamon
18:37:07 <paragan> I see somewhere asked again should we consider spins as a self-contained or system wide change
18:37:20 <rishi> +1 to Cinnamon. Not sure whether we need a Netizen spin.
18:37:24 <dgilmore> the netizen one I would like it to be a bit clearer what it actually is
18:37:26 <nirik> definitely fine with cinnamon +1. There was still some discussion on the other one.
18:37:47 <paragan> yeah +1 to cinnamon spin
18:37:54 <sgallagh> +1 to Cinnamon as well
18:38:02 <nirik> I think the idea is nice, but they seem to just provide the privacy/etc tools, but not really any integration work.
18:38:07 <ajax> presumably it comes with a mail client that refuses to top-post
18:38:17 <rishi> ajax: :D
18:38:20 <nirik> ha.
18:38:31 <jkurik> nirik: exactly, it is my feeling as well
18:38:34 <nirik> it has basically tor/privoxy/keepassx/etc...
18:38:52 <ajax> +1 to cinnamon
18:39:17 <sgallagh> Netizen seems to me like it should be a process and an educational effort rather than a product
18:39:18 <nirik> so, what would we like to do on it? defer and engage with owner some more on list?
18:39:33 <ajax> the netizen thing seems more like a product?
18:39:38 <rishi> I would have been happier if they signed up add a "certificate pinning" UI to seahorse instead. Just a random example.
18:39:47 <ajax> the distinguishing feature of spins at this point seems to be "hey check out my default desktop"
18:39:56 <nirik> sgallagh: well, I think it could be a showcase... "here's how to setup things to be more private"
18:40:11 <sgallagh> nirik: A youtube video could handle that more easily, I think
18:40:11 <nirik> but that would take actually doing that config...
18:40:14 <jwb> ajax, basically.  i'm not convinced this is at all worthwhile
18:40:18 <dgilmore> ajax: there is two types of spins
18:40:24 <dgilmore> the desktop ones
18:40:29 <rishi> ajax: Actually I got it the other way round. Netizen, to me, looks like a bunch of packages installed by default.
18:40:43 <dgilmore> and then the things like security, games, scientifc, design suite
18:40:56 <rishi> Cinnamon, to me, is more like a finished cohesive entity.
18:41:10 <nirik> the new websites divide them into 'spins' (the desktops) and 'labs' (the other collections of stuff)
18:41:13 <ajax> dgilmore: huh, so there's the kind mentioned on spins.fp.o, and the kind not mentioned on spins.fp.o.
18:41:15 <jwb> dgilmore, the latter is "stuff i install after on my machine so i might as well make a spin"
18:41:29 <dgilmore> ajax: labs.fp.o
18:41:39 <nirik> http://labs.fedoraproject.org/
18:41:41 <dgilmore> jwb: kinda yeah
18:41:42 <rishi> But, but ...
18:41:51 <rishi> I don't like KDE, but I like games.
18:41:55 <rishi> So what spin do I use?
18:42:12 <rishi> I never understood the point of the "labs".
18:42:13 <nirik> they are more like 'you just want to do X and we have a X spin, just use that'
18:42:15 <ajax> see, choice sucks.
18:42:15 <jwb> labs would be AMAZING if it was just a "build me a spin from this supplied kickstart" tool
18:42:18 <ajax> told you.
18:42:18 <rishi> Those are just stuff that I can install.
18:42:19 <dgilmore> rishi: you make your own, or put the games on prefered desktop
18:42:20 <jwb> otherwise, it's kind of pointless
18:42:21 <rishi> ajax: ;)
18:42:26 <nirik> webrevisor!
18:42:33 <jwb> nirik, basically.
18:42:49 <nirik> most of the 'labs' are also comps groups.
18:43:07 <jwb> while i may hold an unpopluar opinion, i don't think having spin images for everything is wonderful for the project
18:43:23 <nirik> you are not alone. ;)
18:43:31 <rishi> jwb: I agree with you.
18:43:44 <sgallagh> jwb: +1
18:43:44 <jwb> so i'm -1 to netizen.  i'm probably -1 to cinnamon too
18:43:49 <nirik> anyhow, proposal: revisit netizen next week and discuss more on list.
18:43:58 <dgilmore> jwb: I do not disagree, some users really like the spins.
18:44:02 <dgilmore> nirik: +1
18:44:18 <paragan> nirik, +1
18:44:32 * jwb goes to create a "kernel developer" spin
18:44:47 <nirik> I think we were at +6/-1 on cinnamon then?
18:44:47 <ajax> jwb: the joke is it installs debian?
18:45:01 <nirik> ajax: freebsd kernel. ;)
18:45:05 <rishi> jwb: microEMACS as default text editor!
18:45:08 <dgilmore> jwb: make sure you include a copy of the fedora kernel source in it
18:45:08 <jwb> ajax, no, because debian moved to systemd too
18:45:13 <ajax> nirik: +1 revisit
18:45:29 <ajax> jwb: right, my bad, i didn't mention which version of debian
18:45:41 <dgilmore> nirik: I believe so for cinnamon
18:45:44 <nirik> #agreed cinnamon spin approved (+6,-1,0)
18:45:45 <ajax> uh, whichever one was libc5 i guess
18:45:46 <jwb> ajax, i mean, if we're going for the stereotype, we might as well be specific
18:46:08 <jwb> ajax, i'll call it the akpm spin and it will literally just be FC6
18:46:11 <nirik> any other votes for revist netizen next week (we are at +4 for that now)
18:46:23 <dgilmore> jwb: go the new world version, make it a kernel developer vagrant box
18:46:26 <sgallagh> nirik: +1 revisit
18:46:50 <rishi> Yes, revisit netizen.
18:47:03 <thozza> nirik: +1 revisit
18:47:03 <nirik> #agreed Further discuss netizen on the list and revisit next week (+6,0,0)
18:47:04 <rishi> Although I might still vote "no" next week. :)
18:47:12 <sgallagh> dgilmore: kidding aside, a kernel developer vagrant that has the fedora config pre-built on it (so modifications are a smaller build) would be fantastic
18:47:21 <nirik> #topic #1435 Approving exceptions to the package review process
18:47:21 <nirik> .fesco 1435
18:47:23 <zodbot> nirik: #1435 (Approving exceptions to the package review process) – FESCo - https://fedorahosted.org/fesco/ticket/1435
18:47:33 <jwb> vagrant implies virtualbox?
18:47:46 <dgilmore> jwb: no, works with libvirt also
18:47:47 <nirik> jwb: there's a libvirt backend now apparently
18:48:08 <jwb> oh good.  because there is no measure to how far i would tell people to ... well, nevermind
18:48:12 <dgilmore> for f22 we made virtualbox and libvirt versions
18:48:14 <sgallagh> jwb: Yeah, libvirt works quite well. I just built one for SSSD development today. Quite easy.
18:48:37 <nirik> so, this is basically the FPC wanting the power to except reviews in rare cases they deem it's ok to do so...
18:49:12 <sgallagh> Well, it was them wanting to know if that power is sensible and if so, who decides when to use it.
18:49:30 <nirik> I'm fine delgating that to them... if they do something we don't like we can always revisit.
18:49:59 <rishi> Yeah. Let's delegate to FPC.
18:50:07 <dgilmore> so I honestly would be okay, if we made sure we had some tooling that produced things sanely. the texlive srpm is a monstrosity, and its often updated for minor changes, spliting it up into 1800 odd srpms makes so much sense
18:50:08 <paragan> yes FPC is good for this
18:50:17 <nirik> although as far as I know the SCL guidelines are stalled and unlikely to ever really happen.
18:50:29 <rishi> Although the way we do package reviews leaves a lot to be desired. Review it once and then let the crazies take over. :/
18:50:40 <nirik> dgilmore: even fewer would help.
18:50:52 <nirik> even 10 would be better than 1 we have now
18:50:57 <rishi> Not sure how to practically fix that, though.
18:50:58 <dgilmore> if we say FPC decide its okay, or ot has to come to FESCo, I am okay either way
18:51:22 <nirik> proposal: delegate authority over exceptions to the package review process to FPC
18:51:26 <nirik> +1
18:51:30 <paragan> +1
18:51:33 <thozza> nirik: +1
18:51:41 <rishi> +1
18:51:44 <dgilmore> rishi: we fix it by having automated checking of things and bugging people when they make mistakes
18:51:49 <dgilmore> +1
18:51:53 <sgallagh> +1
18:52:03 <ajax> +1
18:52:16 <dgilmore> rishi: as in run rpmlint, etc automatically after every build
18:52:32 <nirik> #agreed delegate authority over exceptions to the package review process to FPC (+7,0,0)
18:52:37 <rishi> dgilmore: Presumably only that that is not good enough. Otherwise we could have automated the initial review too.
18:52:39 <sgallagh> nirik: That implies but does not explicitly state that mass-imports are acceptable.
18:52:45 <jwb> +1 btw
18:52:56 <nirik> sgallagh: well, 'exception' I thought covered it?
18:53:16 <nirik> do you want to add a patch or counterproposal?
18:53:20 <sgallagh> Nah.
18:53:21 <nirik> #undo
18:53:21 <zodbot> Removing item from minutes: AGREED by nirik at 18:52:32 : delegate authority over exceptions to the package review process to FPC (+7,0,0)
18:53:21 <dgilmore> rishi: I think its good enoough to detect undesired changes
18:53:26 <nirik> #agreed delegate authority over exceptions to the package review process to FPC (+8,0,0)
18:53:27 <sgallagh> nirik: It's probably fine.
18:53:34 <nirik> #topic Next week's chair
18:53:39 <nirik> who wants the chair next week?
18:53:41 <sgallagh> I'll take it; it's been a while
18:53:50 <nirik> #action sgallagh to chair next week
18:53:51 <nirik> thanks.
18:53:54 <nirik> #topic Open Floor
18:53:58 <nirik> anything for open floor?
18:54:09 <dgilmore> I have nothing
18:54:23 <sgallagh> #info Congratulations on the Fedora 22 release!
18:54:38 <dgilmore> actually I do
18:54:41 <nirik> Yeah, great work from everyone. ;) Congrats.
18:55:00 <dgilmore> I will not be here next week, I will be busing in meetings and prep for the releng fad next weekend
18:55:08 <dgilmore> busy
18:55:36 <nirik> ok.
18:55:41 <dgilmore> the plan is by the end of next weekend rawhide will look very different
18:55:42 <nirik> Hope it's a great FAD. ;)
18:55:57 <dgilmore> nirik: indeed
18:56:18 <nirik> #info releng FAD next weekend.
18:56:35 <rishi> dgilmore: Sounds like fun.
18:56:52 <nirik> if nothing else will close out in a random number of seconds.
18:56:56 <dgilmore> rishi: hopefully it is, along with productive
18:57:10 <rishi> Looking forward to what you come up with.
18:57:19 <rishi> nirik: Nothing from me.
18:57:46 <nirik> ok, thanks for coming everyone!
18:57:49 <nirik> #endmeeting