17:02:46 <abadger1999> #startmeeting fesco
17:02:46 <zodbot> Meeting started Wed Jun 11 17:02:46 2014 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:54 <dgilmore> hola
17:03:15 <abadger1999> #meetingname fesco
17:03:15 <zodbot> The meeting name has been set to 'fesco'
17:03:21 <abadger1999> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
17:03:21 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
17:03:26 <nirik> morning.
17:03:28 * notting is here
17:03:29 <abadger1999> #topic init process
17:03:30 <t8m> hi all
17:03:35 <mitr> Hello
17:03:47 <abadger1999> mattdm and pjones said they'd be unable to attend today.
17:03:51 <sgallagh_afk> .hellomynameis sgallagh
17:03:51 <zodbot> sgallagh_afk: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:04:05 <dgilmore> .hellomynameis ausil
17:04:06 <zodbot> dgilmore: ausil 'Dennis Gilmore' <dennis@ausil.us>
17:04:30 <abadger1999> Well, that's quorum
17:04:40 <abadger1999> #topic #1311 Disable syscall auditing by default
17:04:47 <abadger1999> .fesco 1311
17:04:48 <zodbot> abadger1999: #1311 (Disable syscall auditing by default) – FESCo - https://fedorahosted.org/fesco/ticket/1311
17:04:53 <abadger1999> Err
17:04:54 <abadger1999> Sorry
17:04:58 <abadger1999> #topic #1221 Product working group activity reports
17:05:01 <abadger1999> .fesco 1221
17:05:04 <zodbot> abadger1999: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
17:05:50 <abadger1999> jwb, pknirsch: Anything from your WGs to note for the past three weeks?
17:05:54 <number80> .hellomynameis hguemar
17:05:54 <zodbot> number80: hguemar 'Haïkel Guémar' <karlthered@gmail.com>
17:06:04 * number80 will represent Cloud SIG
17:06:20 <abadger1999> number80: Cool.  Looks like it's progressing -- anything to note?
17:06:26 * jreznik is around
17:06:39 <jwb> abadger1999, not particularly.  there were some discussions on whether to include virt by default, and the lack of votes and process.  aside from that, typical low-level work
17:06:39 <number80> we're trying to get more folks involved in writing tests scenarios
17:06:57 <abadger1999> <nod>
17:07:05 <abadger1999> jwb, cool.
17:07:27 <dgilmore> jwb: my personal opinion is that we should include virt
17:07:31 <nirik> server has been working on the roles api, etc.
17:08:20 <jwb> fwiw, i think we should close the existing "WG updates" fesco ticket.  it's just going to get longer and longer, which makes it harder to read
17:08:29 <number80> +1 jwb
17:08:34 <abadger1999> jwb, dgilmore: is virt-by-default in desktop something that fesco should be talking about or should I just direct that discussion back to desktop discussion ;-)
17:08:52 <jwb> abadger1999, the WG.  they know about it already.  you asked for a status update
17:08:53 <abadger1999> jwb: yeah -- that makes sense to me... we just have to make sure it is on the agenda bi-weekly.
17:08:58 <abadger1999> <nod>
17:09:15 <dgilmore> abadger1999: I think its should just go back to WG, i was just stating my personal opinion
17:09:21 <abadger1999> Cool.
17:09:22 <sgallagh> jwb: The lack of response/votes: *that* might be worth discussing in FESCo
17:09:50 <abadger1999> #info discussion in desktop WG about virt by default.  Discussion ongoing in the WG.
17:10:01 <jwb> sgallagh, maybe if it doesn't improve.  discussing it now is, frankly, not going to help anything.
17:10:14 <sgallagh> jwb: Fair enough. I trust your judgement there.
17:11:02 * nirik is +1 to closing existing ticket. we can open a new one next time
17:11:14 <sgallagh> nirik: The Fedora Server Role API is (I think) finished now. The states were the last thing requiring discussion, and I think we're settled there now.
17:11:21 <nirik> yeah
17:11:25 <abadger1999> nirik: I'll add something to the meeting process page about that too.
17:11:27 <sgallagh> API *design* to be clear
17:11:40 <nirik> abadger1999: sounds good.
17:11:43 <t8m> abadger1999, getting it on agenda bi-weekly can be ensured by adjusting http://fedoraproject.org/wiki/FESCo_meeting_process
17:11:49 <abadger1999> Okay -- so sgallagh seems like we should discuss the server status
17:12:09 <abadger1999> #topic Server WG, Roles API, and potential schedule slip
17:12:17 <abadger1999> sgallagh: Take it away, sir
17:12:42 <sgallagh> So the basic situation is this: we budgeted for a certain amount of API design time and then implementation time.
17:13:07 <sgallagh> A combination of a false start and the incorporation of input from the CentOS Simple Linux Server SIG set us back about two weeks.
17:13:38 <sgallagh> I believe that the implementation time estimate remains accurate, so we voted to ask FESCo up front for a two-week extension on implementation.
17:13:53 <sgallagh> (Noting that it's not useful to land this after Feature Freeze)
17:14:30 <sgallagh> ("useful" may be the wrong word. It won't get sufficient testing in Alpha)
17:15:16 <abadger1999> We knew up front that fedora.next would be fraught with big changes that could cause delays so I'm not opposed to this on the surface.
17:15:20 <sgallagh> Rather, part of this feature will include installer functionality.
17:15:23 <drago01> well I don't think we should slip until its *really* needed ... we have already delayed that release for way to much
17:15:28 <abadger1999> There were some concerns on the list that F20 is getting long in the tooth, though
17:15:32 <sgallagh> Not having this in the Alpha means that only Beta will be available to fix installer issues
17:15:37 <mitr> sgallagh: So to clarify - are you proposing a slip?
17:15:53 <nirik> we are about 5ish weeks from alpha change freeze
17:16:08 <jreznik> two weeks, with actual action plan is still pretty much affordable
17:16:13 <mitr> AFAICT the situation is: we really must get this in for the Alpha deadline, and what we likely need is an extension of the Changes Freeze for this change
17:16:41 <sgallagh> mitr: yes, it needs to be there for Alpha
17:17:15 <nirik> we are a monthish out from that...
17:17:27 <t8m> sgallagh, are you reasonably certain that the extension will be needed and that two weeks will suffice?
17:17:33 <sgallagh> So if we're okay with this landing on July 21st (a day before Alpha Freeze), that should also be acceptable
17:17:35 <nirik> are we likely to have any better ideas on implementation time if we defer for a week or two?
17:18:08 <sgallagh> nirik: Well, as with all things, we're unlikely to be absolutely certain until the last week before the deadline :-/
17:18:19 <dgilmore> I think we are way too early to be talking about slippages
17:18:27 <sgallagh> But right now, twoerner estimates that he's going to need a little more time.
17:19:03 <jreznik> dgilmore: well, the idea for changes is actually to plan and if server guys think it's the release blocking change/feature, it makes sense to plan release based on this request
17:19:18 <sgallagh> As I said, if FESCo wants to rule that this Change is allowed to land at Alpha Freeze instead of Change Freeze, that is probably good enough
17:19:18 <nirik> sgallagh: sure, but a month is a while... perhaps it will go better than expected. ;) since the api hasn't been nailed down until just recently there's likely not been implementation started, so I bet the next week will tell somewhat
17:19:44 <dgilmore> jreznik: we should keep an eye on it. But I think its too early to change the schedule
17:20:07 <jreznik> sgallagh: I'm ok with it
17:20:29 <dgilmore> I am okay with it landing at alpha freeze
17:20:38 <notting> if twoerner already thinks he may need more time this far out, that does seem like a warning sign.
17:20:44 <sgallagh> nirik: Well, a month is a while... anytime except vacation season :)
17:21:10 <notting> i'd be provisionally OK with it landing at alpha freeze, but in general seems like maybe waiting a week or two for clarity is better
17:21:24 <sgallagh> notting: The concern is because he's got other duties as well, particularly firewalld.
17:21:58 <dgilmore> notting: indeed
17:22:03 <t8m> I am +1 to allowing landing at Alpha Freeze
17:23:53 <abadger1999> sgallagh: how much does server role api affect things utside of the server product?
17:24:13 <sgallagh> abadger1999: Very little
17:24:36 <sgallagh> It should be mostly self-contained.
17:25:00 <jwb> i think you should be gathering feedback from the other WGs before really deciding anything on schedule.
17:25:01 <sgallagh> We were originally going to try to add an anaconda plugin to support the roles, but we decided that was too ambitious for the first release
17:25:02 <abadger1999> k I'd be okay with either landing at alpha freeze or slipping
17:25:10 <abadger1999> We may end up doing both in the end :-/
17:25:53 <dgilmore> I really do not want to slip unless its totally necessary, right now we can't know if it is
17:25:56 <nirik> jwb: +1. There may be other groups with concerns.
17:26:17 <jreznik> maybe let's try now alpha freeze, get more feedback in next week, two weeks, ask wgs, I'll help there
17:26:23 <sgallagh> jwb: That's fair. My primary goal here was to communicate the risk so it doesn't surprise us down the line
17:26:26 <notting> jwb: feedback on list by individual WS members was they seemed to be against a slip. not much from cloud.
17:26:32 <sgallagh> (bingo?)
17:26:38 <t8m> I think we could allow for now landing at Alpha Freeze and slip only if completely necessary - that is we should wait with slipping before it is clear it is needed and that a week or two will suffice
17:26:48 <jreznik> sgallagh: thanks for communicating it early
17:26:52 <number80> notting: i'm against it but I can't speak in the name of the whole cloud WG
17:26:58 <jwb> notting, well, they've had less than a day...
17:27:04 <abadger1999> jreznik: that works for me
17:27:33 <number80> I'll add it to the agenda of the cloud WG weekly meeting (tomorrow)
17:27:57 <abadger1999> I think there's one thing we could also discuss now..
17:28:18 <abadger1999> fesco could tell the server WG to take the server role api off the table if it's going to require more time.
17:28:35 * sgallagh notes that FESCo has previously asserted that the three Products will share a release schedule for Fedora 21. That does seem to mean that if any of the three has a blocker slip, they all do.
17:28:40 <nirik> it's kinda central to things.
17:28:59 <sgallagh> abadger1999: That's tantamount to telling the Fedora Server to defer to F22
17:29:11 <sgallagh> Which is within FESCo's power. I wouldn't love it, though.
17:29:19 * nirik is very strongly against different release cycles for f21 at least.
17:29:28 <notting> abadger1999: i think that depends on how much time is needed - it's not reasonable (IMO) if one day is needed, it's totally reasonable if six months is needed
17:29:29 <drago01> sgallagh: not really ... its not like its useless without that api
17:29:31 <jreznik> sgallagh: well, we probably need something like we have for spins to say, if product is ready to be released or not
17:29:35 <dgilmore> sgallagh: we can not deliver products with different schedules
17:30:09 * dgilmore is strongly against different release schedules ever
17:30:10 <sgallagh> dgilmore: I agree. It was more to remind people that the Products aren't separate.
17:30:22 <dgilmore> :)
17:30:23 <jreznik> drago01: if server wg thinks it's that required change, maybe even product release could be skipped
17:30:33 <abadger1999> sgallagh: yep.  I think it's good to talk about that now, though, so that if we're down the line a few months and blocker bugs are discovered in server role api, no one's surprised if we slip then.
17:30:39 <sgallagh> drago01: Without that API, at this point the Server WG would really have no value as a Product.
17:30:47 <nirik> drago01: then it's just an image with some packages on it.
17:30:55 <dgilmore> so we know there is something to keep an eye on, try get resources for if needed
17:31:33 <drago01> nirik: well which all products more or less are but ok
17:31:38 <jreznik> sgallagh: how much "no way" would be for server wg idea of skipping the whole f21 release and releasing only two products in this case?
17:32:48 <sgallagh> jreznik: I think that would be hugely demoralizing
17:33:23 <nirik> proposal: gather feedback and info, revisit next week with hopefully some more data
17:33:27 <dgilmore> I really do not think it makes sense to not deliver anything for server in f21
17:33:49 <jwb> jreznik, i think that would be extremely confusing to everyone
17:33:58 * sgallagh notes that a lot of people have been putting real effort into delivering this.
17:34:02 <abadger1999> I think I like t8m's proto-proposal better
17:34:14 <sgallagh> t8m: Mind making a formal call for votes?
17:34:16 <jwb> the amount of discussion and promotion around fedora.next has centered squarely on 3 products.  shipping only 2 would be pointless
17:34:19 <mitr> jreznik: “no way just because we can't get 2 weeks of pre-alpha testing”.  (Assuming the WG members would actually test the new functionality, more than many upstream rebases in rawhide are tested.)
17:34:24 <t8m> ok
17:35:12 <sgallagh> mitr: That's a reasonable assumption, given that they are the ones developing it, not just some random upstream
17:35:33 <t8m> #proposal The Server roles API is allowed to land after the Feature freeze and before the Alpha freeze, any schedule slipping will be decided later
17:35:41 <mitr> sgallagh: I think so too (but it is an assumption and I wanted to disclose it)
17:35:42 <jreznik> well, one day, especially if that doors for more products will open, we would need some readiness check for products same as for spins... just saying
17:35:43 <sgallagh> t8m: +1
17:35:51 <abadger1999> t8m: +1
17:35:57 <t8m> +1 to myself
17:36:02 <nirik> alright, sure, +1
17:36:09 <dgilmore> +1
17:36:34 <notting> t8m: +1
17:36:48 <mitr> t8m: Given that this has passed, +1 (otherwise, sitting on two chairs like this, it‘s a little uncomfortable)
17:37:12 <jreznik> s/Feature Freeze/Change Freeze :)
17:37:17 <sgallagh> mitr: Well, by that logic, nirik and I should also not count :-P
17:37:23 <abadger1999> #info The Server roles API is allowed to land after the Feature freeze and before the Alpha freeze, any schedule slipping will be decided later APPROVED: (+1:7, 0:0, -1:0)
17:37:24 <t8m> jreznik, yep, sorry for that :)
17:37:31 <abadger1999> #undo
17:37:31 <zodbot> Removing item from minutes: INFO by abadger1999 at 17:37:23 : The Server roles API is allowed to land after the Feature freeze and before the Alpha freeze, any schedule slipping will be decided later APPROVED: (+1:7, 0:0, -1:0)
17:37:38 <abadger1999> #info The Server roles API is allowed to land after the Change freeze and before the Alpha freeze, any schedule slipping will be decided later APPROVED: (+1:7, 0:0, -1:0)
17:38:31 <mitr> sgallagh: I'm not sure about this; I think the right thing to do is to vote anyway, but to make sure the dual loyalties are understood.
17:38:33 <abadger1999> jreznik: Will you also reach out to the other WG's to let htem know that we've done what we can but blockers in other Products could still cause schedule slippage for everyone?
17:38:44 <jreznik> sure
17:38:50 <abadger1999> jreznik: thanks.
17:39:05 <sgallagh> mitr: I meant that it's only +4 if all three of us abstain.
17:39:27 <abadger1999> Do we want to talk about potential rebases to big things like X in f20?  Or wait for a solid proposal to materialize?
17:39:31 <sgallagh> But I think it's fair to vote in this case since we're representing acceptance of a compromise
17:39:43 <sgallagh> abadger1999: I vote that we wait for a proposal
17:39:45 <dgilmore> abadger1999: wait for a proposal to come up
17:39:46 <abadger1999> wfm
17:39:50 <nirik> wait yeah
17:40:00 <sgallagh> At this point we're definitely in spitting distance of F21 alpha at least
17:40:01 <abadger1999> #topic #1311 Disable syscall auditing by default
17:40:02 <mitr> Yeah, that seemed like a reaction to an assumed very long slip
17:40:03 <abadger1999> .fesco 1311
17:40:04 <zodbot> abadger1999: #1311 (Disable syscall auditing by default) – FESCo - https://fedorahosted.org/fesco/ticket/1311
17:40:05 <sgallagh> The extra work may be just that
17:40:27 * sgallagh really wishes he had said "two weeks" in the original message. That was a foolish error.
17:40:40 <nirik> so, on this were we going to wait for some benchmarking ?
17:41:20 <abadger1999> So we've had some input on this -- dwalsh says that it wouldn't cripple the ability to debug selinux denials.  But everyone wants there to be a performance regression that could be fixed instead.
17:41:21 <notting> ... indefinitely? or did someone signup to do it?
17:43:06 <sgallagh> This seems like the sort of performance issue that Red Hat would want to address as well. Perhaps we can ask Daddy Shadowman to have the perf team look into it for us?
17:43:18 <t8m> sgallagh, +1
17:43:30 <abadger1999> Looks like there was a request for benchmarks and the reporter added this: https://fedorahosted.org/fesco/ticket/1311#comment:2
17:43:45 <abadger1999> No furhter request for benchmarks since then.
17:44:18 <sgallagh> abadger1999: "I would love to see more numbers." comment 22
17:44:32 <t8m> abadger1999, the benchmarking should be done against older RHEL/CentOS releases to find out whether there is actual regression or whether auditing enabled was always so expensive
17:44:36 <sgallagh> (Admittedly today)
17:45:01 <abadger1999> t8m: <nod>  Could you add that to the ticket so the reporter knows what they need to be testing?
17:45:48 <mitr> notting: AFAICT this FESCo ticket was filed just a day after https://www.redhat.com/archives/linux-audit/2014-May/msg00103.html , pursuing multiple paths to get the same result; at least to my knowledge this is not an escalation of a long-ignored problem (but I could be wrong about this)
17:46:01 <sgallagh> Proposal: Ask the reporter to compare RHEL 6 to Fedora Rawhide. If there is a notable difference, report it to Red Hat's performance team for investigation.
17:46:42 <jwb> sgallagh, um.
17:46:44 <sgallagh> (rephrase: s/report it/FESCo will report it/)
17:46:48 <abadger1999> sgallagh: Hmm... question -- is RHT's performance team something that you might know the proper channels?  I doubt a random fedora contributor would know that.
17:46:54 <abadger1999> heh, cool :-)
17:47:28 <jwb> sgallagh, perhaps "old kernel"?  requiring them to install an entirely different OS they might not readily have access to seems overkill.
17:47:54 <jwb> sgallagh, if Red Hat wants to compare upstream versus rhel6, that's different.  the reporter shouldn't need to do that though
17:48:20 <sgallagh> jwb: "Fedora 11" then?
17:48:29 <mitr> sgallagh: If the audit maintainers really do "suspect" that this is just a performance regression, the preferred channel to get all of this done (with patches and detailed discussion) would surely be linux-audit.  The performance team can provide more benchmarks as needed but will probably not be replacing the regular linux-audit posters for doing the work.
17:48:57 <sgallagh> ok, I feel like we're arguing about the details more than the overall approach, though
17:48:57 <abadger1999> sgallagh: also note: It seems like dwalsh is okay with disabling this if there is a large performance win.
17:49:05 <jwb> sgallagh, that's still an entirely different OS
17:49:07 <sgallagh> "See if it's a regression, ask the right people to fix it if so"
17:49:10 <notting> mitr: oh, this is a fun thread. "I think that it's silly to let the auditsc design be heavily constrained by ia64 considerations"
17:49:15 <mitr> I’d really love to hear Eric Paris’s assesment
17:49:27 <abadger1999> whcih could be a vote for disable in fedora until the performance is brought back up.
17:49:43 <sgallagh> mitr: I believe he's been on PTO, which is unfortunate timing
17:49:49 <mitr> sgallagh: yes
17:50:37 <mjg59> Proposed option 4 avoids the performance hit while doing nothing to prevent a user from enabling their own audit policy, right?
17:50:45 <notting> that being said, i don't think changes here impact so much that it matters if we wait
17:50:56 <mitr> notting: In the meantime, some of the referred things (x32 in particular) are being actively addressed.  So _something_ is happening but I don’t know enough to say whether it will, may, or will not address the performance concerns.
17:51:02 <mjg59> And if dwalsh doesn't see the need for it, I don't see any obvious benefit in having syscall auditing enabled by default
17:51:13 <mjg59> We don't do anything with the data
17:51:19 <mitr> mjg59: AFAIK you can't reenable auditing for a PID after it has started, i.e. “yes if you are fine with having to reboot”
17:51:33 <notting> mitr: true. but x32, like ia64, is not a fedora concern
17:51:56 <mitr> notting: There were/are? crashes and the like triggerable without a real x32
17:52:25 <abadger1999> mjg59: With caveats:  "If you remove '-a task,never' and then add some new rules, pre-existing processes might not respect the new rules until a restart." https://fedorahosted.org/fesco/ticket/1311#comment:16
17:52:25 <mitr> notting: True; we surely won’t do this for F20, so there’s time for F21.  I suppose we should have a decision by the Change Deadline
17:53:28 <notting> i'd be ok with 'if you're setting up syscall auditing, you need to edit the rules and reboot'
17:53:41 <t8m> notting, +1
17:53:41 <abadger1999> <nod>
17:53:46 <sgallagh> notting: +1
17:53:46 <jwb> abadger1999, disabling it in the kernel requires you to install a new kernel and reboot.  with -a task,never you just have to edit a text file and reboot.
17:53:49 * nirik too
17:53:50 <mitr> mjg59: dwalsh is actually saying that the PATH records are useful, but unsure whether they are enabled by default, and disabling it "would not be devastating"
17:54:08 <mitr> notting: +1
17:54:10 <jwb> abadger1999, so... rebuild kernel, install, reboot.  or edit text file, reboot.
17:54:26 <abadger1999> jwb: Yeah.
17:56:30 <nirik> I guess I'd prefer to defer, since sgrubb said he didn't have time to look at it last week and wanted eparis to look as well...
17:56:38 <nirik> https://fedorahosted.org/fesco/ticket/1311#comment:18
17:56:41 <abadger1999> k
17:56:59 <abadger1999> Proposal: Defer for a week to give eparis a chance to give input
17:57:03 <nirik> +1
17:57:07 <t8m> +1 to defer
17:57:08 <sgallagh> +1
17:57:10 <abadger1999> +1
17:57:16 <jwb> you might want to send him a direct email
17:57:24 <jwb> i'm sure he has quite a bit of catching up to do
17:57:25 <dgilmore> +1
17:57:26 <mitr> …. Proposal: Ask audit maintainers to to look at the performance again; lacking any input by Change Deadline -1 week, tentatively agree with the -a task, never thing
17:57:39 <abadger1999> #action abadger1999 will send eparis a direct email to look at this ticket.
17:57:46 <mitr> abadger1999: That works too
17:58:13 <notting> abadger1999: sure, +1
17:58:37 <sgallagh> mitr: Save that one for next week :)
17:59:25 <abadger1999> #info Defering disable of syscall auditing for 1 week while seeking input from eparis (+1:6, 0:0, -1:0)
17:59:40 <abadger1999> #topic #1310 Reconsidering rpcbind's exception allowing it to start by default
17:59:42 <abadger1999> .fesco 1310
17:59:43 <zodbot> abadger1999: #1310 (Reconsidering rpcbind's exception allowing it to start by default) – FESCo - https://fedorahosted.org/fesco/ticket/1310
18:00:06 <abadger1999> No input from steved in the past week.
18:00:23 <abadger1999> What do we want to do here?
18:01:44 <mitr> Considering that if we drop the exception, it would be up to steved again to apply it (or, well, provenpackager)…
18:01:45 <sgallagh> If the original statement is true, that rpcbind isn't useful without configuration anyway, I'd say disable it
18:02:46 <abadger1999> sgallagh: well... what it really says is that rpcbind works without conf but the only service known to be using it is nfsd which requires config.
18:03:56 <notting> repoquery implies its use by am-utils, bootparamd, rusers, rwall, ypbind, ypserv, a nagios plugin, and glusterfs
18:04:35 <notting> which sounds like 'glusterfs and seven things you shouldn't be using anyway'
18:04:46 * sgallagh chuckles
18:05:15 <mitr> My preference would be to have it disabled on new installs, and unmodified on upgrades.  Can we do that?
18:05:23 <abadger1999> :-)
18:05:39 <sgallagh> mitr: Yes, easily
18:05:43 <notting> mitr: swapping enable for preset would seem to do just that
18:08:15 <abadger1999> mitr: Care to make that a proposal and we can vote on it
18:08:15 <t8m> we definitely should not disable it on upgrade but that is easily achievable
18:10:33 <mitr> We do end up giving up on a "zero-setup NFS<=3 client" by this, don't we?
18:11:25 <mitr> Proposal: Drop the rpcbind exception, file a bug against rpcbind to use (systemctl preset) instead of (systemctl enable)
18:11:53 <dgilmore> mitr: +1
18:12:05 <notting> mitr: +1
18:12:07 <abadger1999> +1
18:12:09 <mitr> [and meta-proposal: $some_other_time, FESCo to figure out how to follow up on these kinds of decisions; we are starting to accumulate a history of things we decide that don’t get done]
18:12:09 <t8m> mitr, +1
18:12:13 <sgallagh> mitr: Anything that kicks NFS<=3 to the curb is a good move in my book
18:12:15 <sgallagh> mitr: +1
18:12:38 <mitr> sgallagh: My enthusiasm for breaking things in name of progress is extremely limited :)
18:13:11 <abadger1999> nirik, mitr: votes?
18:13:20 <mitr> abadger1999: +1 for the record
18:13:22 <nirik> +1
18:13:27 <sgallagh> Not so much "in the name of progress" as "In my experience, NFSv3 has only ever worked either by accident or by the labor of a dozen people for weeks"
18:13:59 <abadger1999> #info Drop the rpcbind exception, file a bug against rpcbind to use (systemctl preset) instead of (systemctl enable) APPROVED: (+1: 7, 0:0, -1:0)
18:14:20 <abadger1999> #topic Resignations and new Members
18:14:56 <abadger1999> So notting, our Senator Byrd, has decided it's time for him to step down ;-)
18:15:07 <notting> so, as stated on the FESCo list, I need to resign my position due to time commitments
18:15:13 <nirik> sorry to hear it...
18:15:23 <notting> and/or 8 year term limits
18:15:59 <dgilmore> notting: Thanks for everything over the years
18:16:10 <t8m> notting, it's a real loss
18:16:13 <sgallagh> notting: So Long and Thanks for all the Fish
18:16:25 <nirik> notting: yeah, do drop by when you have time from time to time. ;) and thanks much for all your work with Fedora.
18:16:35 <sgallagh> Any time you wise up and want to come back, I'm sure there will be a place for you :)
18:16:57 <mitr> notting: Sorry to see you leave
18:17:33 <abadger1999> notting: Thanks for being around to straighten out all of my stupid ideas over the years ;-)
18:17:38 <notting> thanks all, it's nice to hear.
18:18:37 <sgallagh> #info FESCo thanks notting for his long and storied service to Fedora.
18:19:54 <abadger1999> From fesco policy the runner ups from the last election get first crack at the seat.  That would be: mmaslano and kylem.
18:20:11 <abadger1999> On fesco list mmaslano was not interested in the seat.  Kyle McMartin was but said "unless we want to have a one-off election"
18:20:43 <abadger1999> So... I'm going to throw one wrench in here and say that I'm also planning on resigning from fesco.
18:20:50 <notting> my seat expires in 'whatever the next election is'
18:20:52 <sgallagh> What were the voting results of last election? Was kylem significantly down?
18:21:08 <sgallagh> abadger1999: Resigning before your term is up?
18:21:08 <abadger1999> Which means we'll be out of runner ups to replace my seat as well.
18:21:11 <abadger1999> sgallagh: yeah.
18:21:21 <sgallagh> oof
18:21:31 <abadger1999> My hope was to be out before flock.
18:21:44 <mitr> sgallagh: https://admin.fedoraproject.org/voting/results/fescof21
18:21:52 <sgallagh> mitr: Thanks
18:22:47 <sgallagh> Ok, so it wasn't an enormous gap (like getting double-digit votes or something)
18:22:49 <abadger1999> So we have some options: The current policy would be: give kyle one seat and fesco discusses among itself who to offer the second seat to.
18:23:05 <abadger1999> Since kyle was willing, we couold also have a special election to elect both seats.
18:23:05 <sgallagh> Proposal: Honor our traditional rules and welcome Kyle McMartin to FESCo
18:23:13 <sgallagh> s/tradtional/published/
18:23:13 <t8m> sgallagh, +1
18:23:30 <abadger1999> offer one and have a special election for the second.
18:23:37 <sgallagh> abadger1999: I think it's poor form to change the policy just as it's being invoked.
18:23:39 <abadger1999> sgallagh: +1
18:23:39 * nirik also sad to see abadger1999 go
18:23:41 <notting> sgallagh: +1
18:23:41 <abadger1999> Works for me.
18:23:51 <nirik> sgallagh: +1
18:23:57 <sgallagh> Let's stick to the existing policy and if we want to change it, let those selected the old way help with it
18:23:59 <abadger1999> That takes care of one of the seats :-)
18:24:11 <sgallagh> abadger1999: Are you planning to retire today, then?
18:24:13 <t8m> we could keep the one seat free
18:24:18 <drago01> abadger1999: seems like you are forced to stay ;)
18:24:29 <abadger1999> drago01: hah :-)
18:24:59 <t8m> and do the next round of elections earlier than on F21 release
18:25:02 <mitr> sgallagh: +1
18:25:07 <t8m> regular elections that is
18:25:18 <dgilmore> +1 to kyle
18:25:35 <abadger1999> t8m: We could but I would recommend having an odd number during the fedora.next transition period... there's sure to be several close votes where an odd number will be a benefit.
18:26:00 * t8m is not fond of close votes
18:26:01 <sgallagh> t8m: http://fedoraproject.org/wiki/FESCo_election_policy#Filling_Vacant_Seats specifically states that we're (FESCo) supposed to recommend a replacement if we can before falling to that option
18:26:07 <abadger1999> #info kylem confirmed to take notting's seat (+1: 6, 0:0, -1:0)
18:26:34 <sgallagh> abadger1999: I was +1 to my own proposal, iof that wasn't clear
18:26:36 <nirik> if abadger1999 isn't stepping down today, perhaps we could all go look around and propose candidates to replace him next week?
18:26:42 <abadger1999> #undo
18:26:42 <zodbot> Removing item from minutes: INFO by abadger1999 at 18:26:07 : kylem confirmed to take notting's seat (+1: 6, 0:0, -1:0)
18:26:45 <abadger1999> #info kylem confirmed to take notting's seat (+1: 7, 0:0, -1:0)
18:26:54 <sgallagh> nirik: That would be my preference
18:26:56 <abadger1999> nirik: that works for me too.
18:27:20 <abadger1999> Like I say, I was hoping to be out by flock but that does give us a few months
18:27:35 <jwb> 2
18:27:36 <abadger1999> Feel free to kick me out earlier if you find a good candidate, though ;-)
18:27:45 * nirik hopes abadger1999 will keep being active in fedora tho. ;)
18:28:01 <abadger1999> Yeah -- I'm planning to concentrate more time on fedora infra and python packaging.
18:28:02 <t8m> nirik, that would be best
18:28:21 <abadger1999> #topic Next week's chair
18:29:34 <sgallagh> I'll chair next week. I'll be out the week after.
18:30:04 <mitr> I’ll be away next week
18:30:46 <abadger1999> #info sgallagh to chair next week's meeting.
18:30:53 <abadger1999> thanks sgallagh
18:31:00 <abadger1999> #info mitr will be away next week
18:31:12 <abadger1999> #info sgallagh will be away two weeks from now.
18:31:17 <abadger1999> #topic Open Floor
18:31:24 <abadger1999> Anything people want to discuss?
18:31:56 <amluto> I incorrectly thought that there was no meeting today, and I can't find logs yet.  Did anyone want my input on the auditing thing?
18:32:10 <sgallagh> "What can we do to avoid scaring people away from FESCo?"
18:32:37 <jwb> sgallagh, er... in what context is anyone scared?
18:32:56 <sgallagh> jwb: It was a joke. We had two resignation announcements today...
18:33:39 <jwb> jokes need winky faces.  they translate poorly in logs otherwise
18:33:54 <abadger1999> amluto: In the end we decided to defer a week.
18:34:01 <abadger1999> amluto: To get input from eparis.
18:34:03 <jwb> amluto, summary was wait for eparis to comment and maybe do a performance comparison between an older kernel and now
18:34:09 <abadger1999> <nod>
18:34:21 <abadger1999> amluto: If you wanted to do that comparison, that would be great.
18:34:27 <jwb> the suggestion was rhel6, but that might be asking much
18:34:54 <amluto> i can try on linode or something.  maybe F20 can boot a really old kernel, too.
18:35:06 <amluto> was there any particular dimension of performance that people especially care about here?
18:35:29 <jwb> nothing specific was mentioned
18:35:38 <amluto> i'll see if I can come up with anything easy.
18:35:42 <sgallagh> amluto: Basically we're looking for whether the performance is a regression or was always that bad.
18:36:06 <mitr> amluto: The question is whether the performance problems you have pointed out are inherent or a regression
18:36:22 <amluto> i don't see code that suggests that it should have been better, but that's all I know without actually trying it
18:37:10 <amluto> anyway, i'll comment on the ticket. no need to keep everyone around right now.
18:37:16 <abadger1999> amluto: Thanks!
18:37:27 <abadger1999> Anything else?
18:38:02 <abadger1999> I"ll close in 60s
18:39:13 <abadger1999> #endmeeting