17:00:54 <sgallagh> #startmeeting FESCO (2012-06-18)
17:00:54 <zodbot> Meeting started Wed Jun 18 17:00:54 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:54 <sgallagh> #meetingname fesco
17:00:54 <sgallagh> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
17:00:54 <zodbot> The meeting name has been set to 'fesco'
17:00:54 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
17:01:05 <sgallagh> #unchair notting
17:01:05 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik pjones sgallagh t8m
17:01:08 <sgallagh> :(
17:01:14 <sgallagh> #chair kylem
17:01:14 <zodbot> Current chairs: abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m
17:01:23 <abadger1999> greetings
17:01:25 <pjones> hello.
17:01:28 <nirik> .hellomynameis kevin
17:01:29 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:01:33 <dgilmore> hola
17:01:37 * abadger1999 adjusts the membership on the meeting page now
17:01:57 <mattdm> .hellomynameis mattdm
17:01:58 <zodbot> mattdm: mattdm 'Matthew Miller' <mattdm@mattdm.org>
17:02:17 <steved> .hellomynameis steved
17:02:18 <zodbot> steved: steved 'Steve Dickson' <steved@redhat.com>
17:02:21 <sgallagh> abadger1999: Just fixed it
17:02:30 <abadger1999> sgallagh: Cool
17:03:31 <sgallagh> kylem and mitr both indicated that they would miss the meeting today
17:03:45 <pjones> congratulations to kylem on missing his first meeting?
17:04:05 <nirik> :)
17:04:08 <pjones> .hellomynameis pjones
17:04:08 <zodbot> pjones: pjones 'Peter Jones' <pjones@redhat.com>
17:04:09 <sgallagh> pjones: It's a noble tradition dating back to the dawn of FESCo
17:04:25 <dgilmore> .hellomynameis ausil
17:04:26 <zodbot> dgilmore: ausil 'Dennis Gilmore' <dennis@ausil.us>
17:04:52 <sgallagh> #topic init process
17:05:13 <sgallagh> Well, oops :-/
17:05:21 <sgallagh> Moving right along...
17:05:22 <sgallagh> #topic #1221 Product working group activity reports
17:05:22 <sgallagh> .fesco 1221
17:05:24 <zodbot> sgallagh: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
17:05:46 <sgallagh> I closed this ticket out
17:05:51 <abadger1999> sgallagh: We did this last week :-)
17:05:52 <nirik> so, did we want to make new ones for this moving forward? or should we just drop this for now?
17:05:58 <sgallagh> But does anyone from the WGs want to give an update today?
17:06:14 <mattdm> I think we do need to find a better way to do coordination.
17:06:16 <nirik> I've noticed that some groups seem to be not as active... but I think lots of work is ongoing to land things before alpha...
17:06:47 <sgallagh> mattdm: You mean waiting for people to shower us with actionable information is a flawed plan?
17:06:57 <mattdm> sgallagh: something like that, yeah :)
17:07:27 <mattdm> I'm not sure I have any immediately actionable ideas right now either though :)
17:07:32 <sgallagh> pknirsch: Are you around. I've heard through the grapevine that Base is feeling blocked on the product WGs, but I haven't heard what you need to proceed.
17:08:31 <sgallagh> Ok, I'll follow up with Phil outside the meeting.
17:08:42 <sgallagh> #action sgallagh to sync up with Base Design and see what they need from the Products.
17:08:43 <nirik> I wonder if we shouldn't do some kind of progress report thing... seems possibly a good time for it?
17:09:11 <mattdm> nirik: do you mean right now at this meeting, or in general across fedora?
17:09:14 <nirik> ie, ask each working group: are you blocked on anything we can help with, do you think things are going well? could we adjust the next plan any to help you?
17:09:17 <jreznik_q10> nirik, I'm planning it for this/next week
17:09:25 <nirik> mattdm: I mean in the working groups...
17:09:42 <jreznik_q10> was a bit more busy than I thought
17:09:46 <nirik> I don't hear much from base, stacks and env, or workstation...
17:09:53 <pjones> nirik: I think that's probably a good idea, but I worry that it can become either a) too infrequently asked, or b) pestering, both too easily.
17:09:57 <jreznik_q10> to cross-check where we are
17:10:00 <nirik> pjones: true.
17:10:19 <jreznik_q10> but we need it, really
17:10:25 * nirik doesn't want to bother, but does want to know before release if we could adjust the plans. ;)
17:10:39 <t8m> Hi, I am sorry for being late
17:10:49 <jreznik_q10> maybe something like pre-readiness meeting..
17:10:58 <mattdm> so, maybe we should ask for a slightly-formal status report from each WG for, say, the 30th?
17:11:07 <nirik> some of that might also take place at flock...
17:11:12 <nirik> (and be higher bw)
17:11:21 <nirik> but not sure how much of each working group will be there.
17:11:22 <sgallagh> nirik: If the status report is happening at Flock, that's *after* Alpha...
17:11:24 <pjones> nirik: no, before.
17:11:31 <pjones> we should be able to *discuss* it at flock.
17:11:34 <mattdm> +1 yes to doing something at flock, but we need something before too
17:11:38 <jreznik_q10> Flock is late
17:11:53 <nirik> agreed. Just saying that adjustments can happen anytime and flock might lead to some. ;)
17:11:55 <dgilmore> Fock is too late
17:12:00 <pjones> I see that kind of feedback as the sort of thing we want everybody to already have in mind when flock happens
17:12:01 <dgilmore> Flock
17:12:07 <sgallagh> Flock is so close to Beta that we should probably be focusing on post-mortems and planning for F22
17:12:12 <dgilmore> but its about right for f22
17:12:35 <jreznik_q10> yeah
17:12:53 <sgallagh> (p.s. holy crap, Flock is a month and a half away)
17:13:01 <dgilmore> sgallagh: indeed
17:13:02 <nirik> time flies. ;)
17:13:03 <mattdm> yeah. :)
17:13:18 <jreznik_q10> I'd like to see that pre-readiness meeting at branch time maybe earlier
17:13:35 <jreznik_q10> not only for WGS but wider audience
17:13:35 <sgallagh> I think mattdm's suggestion of June 30th is probably about right
17:13:46 <mattdm> so, just weighing the balance between infrequent and pestering -- should we ask for more formal _monthly_ reports? (aimed not just at FESCo but for the rest of the project as a whole)
17:14:01 <dgilmore> wwe are 3 weeks from Change freeze and branching
17:14:11 <sgallagh> mattdm: While we're dreaming: can we get those in the form of monthly blog posts?
17:14:42 <jreznik_q10> dgilmore, usually two weeks before I start nagging people for statu
17:14:46 <mattdm> sgallagh or at least something we can put on the fedora magazine. yes. honestly I don't think that's too much to ask for.
17:14:50 <t8m> sgallagh, yeah that would be really nice :)
17:14:53 <dgilmore> jreznik_q10: :) so next week
17:15:07 * nirik nods.
17:15:09 * sgallagh is working on a blog post for Fedora Server this week to cover the Server Role design
17:15:18 <pjones> mattdm: let's see what kind of response we get from one before we codify more?
17:15:32 <jreznik_q10> +1
17:15:33 <pjones> Proposal: ask the WGs for slightly-formal status reports to be delivered on the 30th of June.
17:15:41 <sgallagh> pjones: +1
17:15:42 * pjones +1
17:16:00 <nirik> s/on/by/ but sure.
17:16:01 <nirik> +1
17:16:11 <dgilmore> +1
17:16:11 <pjones> well, our meeting would be on the 2nd, right?
17:16:30 <mattdm> +1 to that
17:16:34 <pjones> so the 30th is 2 days before that, leaving some time to be early or late while we still get to read it before the next meeting.
17:16:35 <sgallagh> Proposal: ask the WGs for slightly-formal status reports to be delivered by 1200 EDT on the 30th of June.
17:16:51 <t8m> pjones, +1
17:17:10 <sgallagh> We should probably also come up with a template or at least a set of questions that need answering
17:17:21 <jreznik_q10> pjones, I'd extend it to other groups too, I'd say bigger changes are happening for websites than all products together
17:17:26 <sgallagh> The most important being "Are you blocked, and how can we unblock you?"
17:17:27 <nirik> WG liasions should communicate this back to their groups. ;)
17:17:49 <pjones> sgallagh: I nominate you to formally ask them ;)
17:17:55 <mattdm> +1 pjones
17:18:15 <pjones> sgallagh: you have great ideas about what we'd like to see in that feedback! :)
17:18:17 <mattdm> jreznik_q10 yeah. and it gives QA further chance to say "help! we are not kidding!"
17:18:35 <sgallagh> pjones: I'll draft something up and send it to the FESCo list
17:18:58 <jreznik_q10> actually websites and docs guys are on track, I'm checking it regularly ;-)
17:19:09 <sgallagh> #action sgallagh to write the first draft of a formal status update for WGs
17:19:27 <jreznik_q10> sgallagh, could you CC me? I'd like to help
17:19:42 <sgallagh> #agreed ask the WGs for slightly-formal status reports to be delivered on the 30th of June. (+6, 0, -0)
17:19:53 <sgallagh> jreznik_q10: Yes, of course.
17:20:42 <jreznik_q10> thanks
17:20:51 <sgallagh> Ok, anything else on this topic?
17:22:20 <sgallagh> #topic #1310 Reconsidering rpcbind's exception allowing it to start by default
17:22:20 <sgallagh> .fesco 1310
17:22:22 <zodbot> sgallagh: #1310 (Reconsidering rpcbind's exception allowing it to start by default) – FESCo - https://fedorahosted.org/fesco/ticket/1310
17:22:51 <steved> sgallagh: I just updated the ticket...
17:22:52 <sgallagh> steved just added a comment on this
17:23:53 <sgallagh> So the need for rpcbind on the client may be the deal-breaker here
17:23:58 * steved admits he not sure want an exception is
17:24:22 <sgallagh> steved: All network-facing services that start automatically have to be approved by FESCo
17:24:25 <nirik> but v2/v3 isn't default too...
17:24:39 <steved> nirik: no V4 is...
17:24:45 <sgallagh> rpcbind has an exception to the rule "No network-facing services may start by default"
17:25:08 <t8m> yeah I think anybody that wants NFSv3 can enable/start rpcbind by themselves
17:25:23 <steved> I think we stop start rpcbind when we stop supporting NFS v3...
17:25:30 <sgallagh> steved: Is v2/v3 usage common enough that we would cause a lot of problems just advising users of it to 'systemctl enable rpcbind' ?
17:26:20 <steved> sgallagh: v3 is the default protocol for a large number of legacy clients...
17:26:48 <amluto> steved: i can't find any easy reference to rpcbind being needed on NFS *client* machines.  can you point me somewhere?
17:26:56 <steved> sgallagh: so yes... there is still a lot of v3 traffic
17:27:04 <sgallagh> ...
17:27:05 <amluto> grepping for rpcbind and 111 in fs/nfs in the kernel didn't find anything
17:27:23 <mattdm> (in my admittedly limited-to-universities experience, v3 is 99% of the real world)
17:27:34 <mjg59> lockd and statd need rpcbind
17:27:36 <steved> amluto: its a userlevel package rpcbind.rpm
17:27:51 <steved> mjg59: yes... they register their ports
17:28:00 <mjg59> But I can't remember whether they're necessary on the client side
17:28:02 <amluto> steved: right, but why does mount -t nfs whatever need rpcbind on the client?
17:28:04 <steved> so other clients can find them
17:28:36 <steved> amluto: do a tshark on the loopback interface.... I'm looking at on right now...
17:28:41 <amluto> but doesn't starting statd or whatever already cause rpcbind to start by systemd dependencies?
17:29:41 <steved> On the server side I think so... but its the client side there is the problem...
17:30:00 <steved> On the client side, the kernel will call up to rpcbind to get the local statd port using the lo interface
17:30:16 <amluto> i must still be missing two things.
17:30:23 <amluto> i can't find that kernel code (which doesn't mean much)
17:30:37 <amluto> and, if the local statd is running, won't that automatically cause rpcbind to start?
17:30:37 <steved> look in net/sunrpc
17:30:39 <sgallagh> steved: local statd port?
17:30:46 <sgallagh> Doesn't that pretty heavily imply statd is started?
17:31:02 <steved> sgallagh: yes...
17:31:25 <sgallagh> Then as long as we ensure that statd has a systemd dependency on rpcbind, I think we're back to being okay.
17:31:50 <steved> sgallagh: I guess... in theory...
17:32:12 <steved> sgallagh: what about commands like rpcinfo that query rpcbind ports
17:32:40 <sgallagh> steved: I'd assume it would get back "rpcbind not running" and then the user would sheepishly go and turn it on.
17:32:52 <mattdm> rpcinfo: can't contact rpcbind: RPC: Remote system error - No such file or directory
17:32:57 <amluto> nfslock.service "Requires" and is "After" rpcbind.service
17:33:36 <mattdm> that doesn't get the award for "world's most helpful error message", but I think anyone used to dealing with nfs or rpc should be used to that :)
17:34:03 <steved> wecome to my world! :)
17:34:21 <t8m> :)
17:34:27 <amluto> if there are no sunrpc services on the local machine, then rpcinfo won't find then with or without rpcbind :)
17:34:36 <steved> sgallagh: Please note all the systemd script change in f21, since i went with the upstream versions
17:35:03 <steved> so please be looking at those
17:35:03 <sgallagh> ...
17:35:20 <sgallagh> steved: Can you pastebin the nfs-lock.service, please?
17:35:43 <sgallagh> mattdm: You're on Rawhide too, could you do so?
17:35:57 <sgallagh> /usr/lib/systemd/system/nfs-lock.service
17:36:02 <nirik> perhaps we should defer this another week ? and debug it out of meeting?
17:36:07 <pjones> indeed.
17:36:13 <steved> sgallagh: I believe that went away...
17:36:27 <sgallagh> Ok, let's take this offline
17:36:35 <sgallagh> Unless we want to make a contingent vote?
17:36:40 * steved agrees...
17:37:08 <sgallagh> Something like "As long as rpcbind is guaranteed to be started with lockd, it should not be started by default"
17:37:11 <mattdm> +1 to debugging out of meeting. but sgallagh: http://paste.fedoraproject.org/110866/03113006/
17:37:13 <steved> sgallagh: give me time to get my head around it... then I'll come with what to do...
17:37:31 <sgallagh> mattdm: So that meets with the requirement.
17:37:33 <steved> sgallagh: how often are these meetings?
17:37:38 <sgallagh> steved: Weekly
17:38:20 <steved> sgallagh: since I'm using the upstream systemd script... I 'll work with them.
17:38:42 <amluto> steved: the current issue is more about the presets file than the rpcbind package
17:39:19 <mattdm> steved weekly, but we can make decisions in between in the ticket :)
17:39:21 <steved> amluto:  sorry I don't know what  a presets file is
17:39:39 <steved> mattdm: I agree....
17:39:52 <sgallagh> steved: It lists the things that are started by default, basically
17:40:06 <sgallagh> Right now, rpcbind is started by default, but NFS services are not
17:40:11 * steved needs to catch up on the systemd terminology :)
17:40:31 * abadger1999 would rather defer a week than do a contingent vote... not sure we know all the variables yet.
17:40:39 <sgallagh> I'm fine with that
17:40:43 <dgilmore> abadger1999: agree
17:40:50 <nirik> +1
17:40:59 <sgallagh> steved: Let's work through this in #fedora-devel after the meeting
17:41:00 <pjones> yeah.
17:41:03 <sgallagh> I think we're 90% there :)
17:41:11 <pjones> Proposal: defer for a week.
17:41:15 <t8m> +1
17:41:17 <sgallagh> +1
17:41:19 <pjones> +1
17:41:25 <sgallagh> (Or until votes occur in the ticket)
17:42:00 <nirik> +1
17:42:00 <steved> thanks!
17:42:20 <sgallagh> #agreed defer for a week
17:42:33 <sgallagh> #action sgallagh to work with steved
17:42:47 <sgallagh> #topic #1311 Disable syscall auditing by default
17:42:47 <sgallagh> .fesco 1311
17:42:49 <zodbot> sgallagh: #1311 (Disable syscall auditing by default) – FESCo - https://fedorahosted.org/fesco/ticket/1311
17:43:00 <sgallagh> Because we don't have enough contentious items on the list this week... syscall auditing!
17:43:19 * amluto aims to please
17:44:36 <nirik> sadly no update from sgrubb
17:44:46 * sgallagh nods
17:44:55 <mattdm> should we ping sgrubb?
17:45:11 <mattdm> and amluto can you come up with some dramtic macro-level benchmark numbers? :)
17:45:14 <nirik> and eparis.
17:45:31 <amluto> mattdm: define drama?
17:45:56 <mattdm> n% performance difference, where n is at least a whole number?
17:46:07 <amluto> well, I got 20% or something with fio
17:46:07 <t8m> amluto, defintely at least a few percents on some macro level benchmark that doesn't just call syscalls
17:46:10 <dgilmore> I really don't think we have enough data and input to make a decision right now
17:46:16 <pjones> with enough samples to do real statistics on it please :)
17:46:40 <pjones> t8m: obviously what we want is benchmarks of random crashme runs
17:46:52 <amluto> TBH, I'm somewhat split between disliking syscall auditing by default because it's slow and disliking it because the code is in awful shape
17:46:57 <pjones> (kidding, kidding.)
17:47:23 <amluto> I suspect that a simple syscall(1000) on i386 Fedora is enough to OOPS, but I haven't tested
17:47:43 <amluto> It oopses on Gentoo, though.  No CVE yet.
17:48:36 <pjones> amluto: huh.  then crashme isn't a bad suggestion, it just isn't a benchmark.
17:49:15 <amluto> seriously, though, if the fio benchmark isn't good enough, what should i look at?
17:49:16 <t8m> amluto, this is not an argument for disabling this is argument for making auditing even more bit rot
17:49:40 <amluto> t8m: it's been on for years, and it's still rotting
17:50:12 <amluto> t8m: i'm not even actively trying to look at it -- i just seem to randomly collect these bug reports
17:50:24 <pjones> It does seem like the options are either disable it or find somebody to love and care for it
17:50:32 <pjones> our track record on the latter is not particularly great.
17:50:33 <amluto> although i have noticed the performance hit all by myself once or twice
17:52:27 * nirik is leaning toward asking it to be disabled, but would still like to hear from sgrubb and eparis about it...
17:53:03 * t8m has no problem with disabling it by the 'never' rule as well
17:53:32 * abadger1999 agrees with nirik's sentiments
17:53:34 <sgallagh> I'd generally prefer that we find someone to actually give some love to the codebase, but since we don't have any magical resources, I'll defer to sgrubb's and eparis's opinions
17:54:13 <amluto> my willingness to give love to the codebase extends only so far as trying to get non-syscall audit records to include syscall number and args
17:54:23 <amluto> which will work even if syscall auditing is off
17:54:35 <amluto> unlikely until 3.17 or 3.18, if at all
17:56:12 <mattdm> proposal: defer until next week for feedback from sgrubb and eparis, and $SOMEONE contact them directly?
17:56:29 <dgilmore> mattdm: +1
17:57:05 <sgallagh> #action mattdm to contact sgrubb and eparis
17:57:07 <t8m> what the feedback should be?
17:57:18 <mattdm> sgallagh fiar enough :)
17:57:57 <nirik> mattdm: +1
17:58:20 <sgallagh> mattdm: +1
17:58:58 <abadger1999> mattdm: +1
17:59:34 <t8m> mattdm, +1 anyway
18:00:16 <pjones> +1
18:00:50 <sgallagh> #agreed defer until next week for feedback from sgrubb and eparis, and mattdm contact them directly (+5, 0, -0)
18:00:59 <sgallagh> #topic #1312 F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
18:00:59 <sgallagh> .fesco 1312
18:01:01 <zodbot> sgallagh: #1312 (F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF) – FESCo - https://fedorahosted.org/fesco/ticket/1312
18:01:29 <sgallagh> Basically two questions here:
18:01:36 <sgallagh> 1) Do we want to approve this for F22?
18:01:54 <sgallagh> 2) Should we make requirements on the name of the CLI tool?
18:02:25 <t8m> I am definitely for keeping the yum compatibility symlink or wrapper.
18:02:32 <dgilmore> sgallagh: before approving it i want to know that all the tools we use that use yum are ported and work
18:02:34 <nirik> I'm +1, although it seems early and we will likely want to revisit it closer to f22 to see whats still missing, etc.
18:02:39 <t8m> (basically forever)
18:02:47 * nirik is with t8m
18:02:56 <dgilmore> sgallagh: I forgot in my email yesterday that all the compose tools will need to be rewritten.
18:02:58 <t8m> and tentatively +1 for approving for F22
18:03:27 <t8m> I have to go away for a couple minutes
18:03:31 <nirik> dgilmore: thats pungi and ? os/appliance-creator?
18:03:34 <dgilmore> sgallagh: and ive not yet started to think about rewriting them
18:03:40 <sgallagh> dgilmore: My assumption is that these are criteria for this Change being complete
18:03:57 <dgilmore> nirik: yeah
18:03:58 <mattdm> dgilmore "all the tools" is pretty broad. I think it's likely that some more obscure utilities will never be ported
18:04:10 <dgilmore> mattdm: sure,
18:04:21 <pjones> Also seems likely that "rewritten" is a bit of a stretch for some of them?
18:04:25 <dgilmore> the tools we use to build and compose fedora
18:04:46 <mattdm> dgilmore *nod*
18:04:50 <dgilmore> pjones: they also all have open bugs for porting to python3
18:04:56 <pjones> true.
18:05:11 <dgilmore> im not opposed
18:05:19 <dgilmore> its just a lot of work not yet started
18:06:07 <sgallagh> I suspect that approving this now will go a long way towards getting appropriate awareness of the impending change out there
18:06:08 <nirik> if they don't get done by f22, then we activate the contingency plan
18:06:17 <pjones> it's still a long way out
18:06:23 * nirik nods
18:07:06 <mattdm> some things like the obsoletes handling make me nervous. I think a lot of the cruft in yum is actually legacy knowledge.
18:07:31 <mattdm> but, plenty of time before f22. :)
18:07:33 <abadger1999> mattdm: I agree... but where does that leave us?
18:09:07 <mattdm> Well, I feel to some degree that the idea to have the command be 'dnf' and 'yum' relegated to a nag script is a defensive move so that when things break, the developers can say "out of design scope!"
18:09:14 <mattdm> which still leaves things broken for users.
18:09:56 <dgilmore> mattdm: i really always thought the plan was to rename to yum when it was ready
18:10:19 <mattdm> I'd rather it be a situation where, when things break, the response is more... oh, we missed that. we'll fix it!
18:10:35 <mattdm> Well, ideally, nothing would ever break. But, you know. :)
18:10:49 <abadger1999> mattdm: That would be my ideal too.  don't know if it's reality or not.
18:11:22 <dgilmore> mattdm: agreed
18:12:24 <mattdm> So....  is that an unreasonble bar for such a fundamental change?
18:13:12 * nirik isn't sure what exactly is being proposed. ;)
18:13:25 <dgilmore> mattdm: we we cant really control how the developers react
18:13:27 <abadger1999> mattdm: might be -- I mean part of the rewrite is also to be able to make changes that the new authors feel make sense.
18:13:33 <pjones> Well, (not) using obsoletes as a discovery mechanism is certainly a pretty serious oversight, but...
18:13:43 <dgilmore> most of the response is due to the developers personalities
18:13:51 <nirik> pjones: how do you mean?
18:13:53 <sgallagh> I think mattdm wants DNF to assume the name 'yum' so we have to treat compatibility issues as regressions
18:14:06 <dgilmore> sgallagh: im +1 for that
18:14:24 <mattdm> We can't (slash shouldn't) control the developers, but we can set some standards for being the default in fedora
18:14:35 <nirik> well, it's planning to?
18:14:39 <pjones> nirik: the issue that came up on f-d-l about discovering what upgrades happen when an obsolete is encountered
18:14:47 <sgallagh> nirik: What is planning to do what?
18:14:57 <pjones> mattdm: so, I mean, why don't we ask them to come to this meeting next week and, you know, talk to them?
18:15:02 <mattdm> and sgallagh yeah, that's basically it. that doesn't mean that everything needs to be 100% compatible, but aiming for basic compatibility is a reasonable request
18:15:09 <mattdm> pjones: absolutely
18:15:15 <jwb> ...
18:15:28 <nirik> dnf will ship with a compat yum that will say "hey, yum is now dnf... redirecting you to dnf... if something behaves differently, it's a dnf bug, thanks. Calling dnf with your command"
18:15:30 <jwb> there is a 100+ long thread on this on the list and you guys just now thought of that?
18:15:36 <pjones> jwb: no?
18:15:44 <jwb> then why didn't you invite them this week?
18:16:20 <pjones> seriously?
18:16:23 <sgallagh> jwb: In all honesty, I was swamped this week and only caught up on that thread this morning after spotting the ticket in the list of 'meeting' keywords.
18:16:35 <sgallagh> So that's pretty much on me,.
18:16:38 <pjones> Because the issue of people in this group not thinking the interaction was working well isn't a thing that was brought up on the thread.
18:17:15 <pjones> And if we need to fix that, we need to fix it by talking directly instead of this back and forth "we can't control developers" alienated stuff.
18:17:25 <mattdm> I was also out most of last week (family stuff) and am getting caught up. *shrug*
18:17:28 <sgallagh> (Though to be fair, I would have hoped they'd see the agenda and pop in of their own volition)
18:17:47 <jwb> pjones, i'd take sgallagh's explanation over "it wasn't explicitly mentioned in the thread" to be honest.  i can't see how someone could read that thread and not already think that
18:17:53 <nirik> personally, I'm ok with the change as it is... we can always adjust moving forward and before we get to f22.
18:18:01 <pjones> sgallagh: yeah, we gotta stop pretending that's a thing.  If we're expecting people to come interact, we have to tell them to.
18:18:02 <mattdm> pjones: you're right. and I apologize for going off down that road.
18:18:03 <jwb> sgallagh, people don't come to meetings voluntarily
18:18:18 * nirik nods
18:19:06 <sgallagh> jwb: Prior to being on FESCo, I attended any meeting where one of my Features was being discussed. But I may be setting the bar a bit high for the general case.
18:19:07 <mattdm> jwb yeah, but we should be better about sending direct invites when people's feature is to be discussed
18:19:48 <nirik> so, where are we here? defer and invite maintainers? send maintainers specific questions?
18:20:12 <mattdm> defer and invite maintainers, yes.
18:20:16 <sgallagh> I'd say let's vote on whether we want this for F22
18:20:24 <sgallagh> If the answer is "no", the point is moot.
18:20:30 <mattdm> I'm not sure if we have general agreement on the specific questions
18:20:43 <sgallagh> Is the switch *truly* predicated on the name of the tool?
18:20:51 <pjones> No, certainly not.
18:20:52 <sgallagh> That seems to me like something that can be easily addressed at the end.
18:21:23 <pjones> Jan (I think?) already said they'd have a /usr/bin/yum link there.  The real question is what is or isn't considered and acceptable level of compatibility.
18:21:33 <mattdm> I'm +1 to doing it for F22, with an extremely strong preference for keeping the yum name (because of cost to users and because of the implications)
18:21:39 <dgilmore> i guess we have two questions, 1) do we want to switch the package installation tool to the codebase currently known as dnf 2) do we want that named yum or dnf
18:21:50 <nirik> mattdm: what does 'keeping the yum name' mean?
18:22:04 <nirik> pjones: yeah, it's in the change page
18:22:04 <abadger1999> I'm thinking defer and invite makes the most sense -- I was thinking I'd +1 knowing that we have a long time until F22 when lots can change... but if we don't open up communication now, it'll end up being F22 change freeze/alpha freeze and we won't have talked about the issues raised here.
18:22:06 <mattdm> I don't think that a yum link that nags you to switch is good. Look what it did for nslookup :)
18:22:22 <pjones> for both users of nslookup ;)
18:22:27 <nirik> "package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own /usr/bin/yum, a short script that redirects to /usr/bin/dnf with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users."
18:22:55 <abadger1999> I think the thing we've been discussing is more about what is the stance on compatibility?
18:23:00 <pjones> you know, there's another interesting effect there
18:23:08 <nirik> then again look at 'ifconfig' and 'ip'. ;)
18:23:16 <pjones> which is that dgilmore's tools don't necessarily need to be fixed by f22 timeframe
18:23:29 <dgilmore> pjones: they could still use yum
18:23:34 <pjones> yeah
18:23:37 <dgilmore> as long as yums not removed
18:23:45 <nirik> right, it should be available still.
18:23:59 <dgilmore> I do kinda think we should switch them if we switch the tool in the os
18:24:01 <nirik> but ideally we move to dnf, so we don't have multiple tools
18:24:33 <pjones> yeah, just saying the timeframe can be laggy
18:24:40 <dgilmore> proit can be
18:24:44 <dgilmore> it can be
18:25:04 <mattdm> nirik 'keeping the yum name' is roughly what rjones suggested in https://fedorahosted.org/fesco/ticket/1312#comment:1 -- existing yum becomes yum legacy, the /usr/bin/yum command is installed by dnf by default and is the primary interface.
18:25:19 <mattdm> I don't think I will block on this, but I have an strong preference.
18:25:20 <dgilmore> pjones: i think my concerns are the least of the hangups
18:25:42 <t8m> I have mostly the same position on this as mattdm.
18:26:15 <dgilmore> mattdm: i welcome the change but have a strong preference to dnf becoming yum-4.0
18:26:16 <nirik> well, that just seems a bit confusing to me...
18:26:41 <nirik> do they intend to merge the dnf and yum git repos upstream?
18:27:06 <mattdm> nirik they are both at baseurl.org
18:27:07 <nirik> "I found a bug in yum!" "please file on dnf" ?
18:28:50 <nirik> anyhow, if we are defering we should do that and move on? ;)
18:28:53 <abadger1999> nirik: eh -- that's not impossible thuogh... rename the dnf repo/bug tracker to yum4... I think naming is somewhat irrelevant though...
18:29:29 <pjones> I really don't think the project name is worth discussion of
18:29:52 <t8m> pjones, +1
18:30:13 <nirik> I guess I should just not care... whatever you want to convince the dnf folks is probibly fine in the end.
18:31:11 <pjones> I think so long as there's a binary named yum that isn't too mean to the user, and there's an appropriate degree of compatibility, it's fine, tbh.
18:31:37 * t8m is +1 to both deferring and/or tentatively approving
18:31:54 <nirik> as far as I can see the yum compat subpackage stuff isn't even written yet...
18:32:16 <nirik> but could also be just a link to dnf... but thats implementation details that dnf maintainers could figure out
18:32:17 <t8m> nirik, this would be fairly trivial
18:32:30 <nirik> agreed.
18:32:35 <pjones> So I guess what we really want to know right now is what concerns we, having now seen 100+ posts about whether or not yum will be a command, actually have for the developers, and what feedback we need from them.
18:34:20 * nirik is fine approving the change as is.
18:34:30 * pjones is too
18:34:48 <sgallagh> as am I
18:36:13 <pjones> everybody else has decided to be quiet now, I guess.
18:36:15 <mattdm> I guess: are they _open_ to revisiting the idea to going to "yum 4", especially given the mailing list discussion? and if not, about making the /usr/bin/yum command only warn in situations which are expected behave differently rather than constantly?
18:36:36 <sgallagh> The latter may be an impossible target to hit
18:37:01 <mattdm> and... really, some of the other concerns about actual compatibility and so on... I'm okay with trusting that that will work out.
18:37:10 <pjones> sgallagh: expected vs do
18:37:44 <sgallagh> mattdm: So is that a +1 to approving the Change?
18:37:48 <pjones> sgallagh: best effort is probably enough there, so long as it's actual effort.
18:37:53 * sgallagh nods
18:38:18 <dgilmore> +1 to approving the change, im sure we can work out the issues as we hit them
18:38:22 <mattdm> sgallagh yeah I actually said above that I'm +1 but with a strong non-blocking preference
18:39:10 <sgallagh> #agreed Fedora 22 will use DNF by default, details will be worked out as we go (+6, 0, -0)
18:39:15 <sgallagh> (Is that a fair summary?)
18:39:18 * abadger1999 doesn't have concerns about the compatibility problems but saw that others here did.
18:39:27 <pjones> sure.
18:39:34 <abadger1999> So I can vote +1 if those others don't care whether their compat concerns are addressed.
18:39:35 <mattdm> And I'm _really_ happy to see big changes like this advanced so early in the development cycle
18:40:03 <sgallagh> abadger1999: I'm covering that under "details will be worked out as we go"
18:40:13 <mattdm> sgallagh: yeah that :)
18:40:36 <abadger1999> <nod>
18:40:43 <sgallagh> #undo
18:40:43 <zodbot> Removing item from minutes: AGREED by sgallagh at 18:39:10 : Fedora 22 will use DNF by default, details will be worked out as we go (+6, 0, -0)
18:40:48 <sgallagh> #agreed Fedora 22 will use DNF by default, details will be worked out as we go (+7, 0, -0)
18:40:55 <sgallagh> #topic Next week's chair
18:41:02 <sgallagh> Come and get it!
18:41:19 <sgallagh> (Side-note, I will not be able to attend next week)
18:41:22 * dgilmore can do it
18:41:36 <sgallagh> #info dgilmore to chair next week's FESCo meeting
18:41:40 <sgallagh> #topic Open Floor
18:42:33 <nirik> Did we want to discuss any about abadger1999's seat? or just discuss on list about that?
18:42:41 <abadger1999> Filling soon-to-be-vacant fesco seat... policy says fesco should just offer it to some qualified people until someone says yes.
18:42:57 <abadger1999> But someone asked if we should just have an election.
18:43:01 <sgallagh> Or, failing that, function with fewer members until the next election
18:43:02 <t8m> I am either for having regular elections round earlier (due to the longer F21 cycle)
18:43:10 <t8m> or for choosing someone.
18:43:15 <pjones> I really think we should have an election.
18:43:20 <sgallagh> I'd prefer not to change FESCo mid-cycle.
18:43:36 <abadger1999> I think we should just nominate some people per the policy.
18:43:45 <pjones> I'm not *really* okay with nominating people who haven't ever stood for election.
18:43:55 <nirik> pjones: election for the one seat?
18:43:58 <abadger1999> pjones: well... that's what the policy says to do, though.
18:43:59 <mattdm> pjones election for all the seats due up on next term, or just the one?
18:44:02 <nirik> or for all people who would normally be up?
18:44:05 <pjones> nirik: no, for all the seats that would be up next round
18:44:15 <abadger1999> and the policy has always been acceptable in the past ;-)
18:44:19 <pjones> plausibly minus the one kyle has already filled.
18:44:23 <nirik> and then again after f21? that would short some terms?
18:44:44 * abadger1999 notes that his seat would not be up next round either.
18:45:03 <pjones> Let me put this a different way.  I don't think when the N-1 group was elected, our voters actually expected we'd be serving this long.
18:45:14 <t8m> pjones, +1
18:45:14 <pjones> As a result, I think we have some questionable legitimacy.
18:45:26 <sgallagh> Our service has traditionally been tied to release cycles, not calendar dates
18:45:38 <abadger1999> sgallagh: +1
18:45:40 <pjones> sgallagh: I think that's true.  I don't happen to think it's /relevant/.
18:45:40 <sgallagh> I think it's imprudent to change the steering community *right before alpha*
18:45:51 <abadger1999> sgallagh: +1 for that as the rationale
18:46:03 <pjones> I don't see how we're not doing that anyway.
18:47:05 <sgallagh> Well, an election has the opportunity to kick out existing seats as well.
18:47:12 <pjones> It does.
18:47:27 <sgallagh> Which seems potentially destabilizing
18:47:36 <pjones> Or potentially the right thing to do.
18:47:43 <pjones> Tricky things, elections.
18:48:20 <sgallagh> I've said this previously: I don't think we should change the policy at a whim.
18:48:34 <sgallagh> If the policy needs changing, allow it to be the first act after the next election
18:48:36 <mattdm> In the last few elections, our problem has been getting enough candidates, not too much churn
18:48:44 <pjones> sgallagh: I find that statement incredibly insulting.
18:49:12 <pjones> I did bring this up when we decided to extend F21's time frame, as well.
18:49:16 <sgallagh> pjones: It... wasn't intended that way?
18:49:27 <nirik> so... we could also go back to the previous election for the seat?
18:49:54 <pjones> (I do want to be clear: I don't have a problem with adamw as a fesco member.  I don't like making random appointments though.)
18:50:36 <adamw> for whatever it's worth, /me is willing to serve if it would be beneficial, but finds it odd there isn't a provision simply to have an election to fill the empty seats
18:50:43 <sgallagh> To be fair, I'm just attempting to follow the codified rules. If we intend to change the rules, I don't think it's necessarily wise to do that *just before invoking them*
18:51:03 <sgallagh> It kind of defeats the purpose of having rules in the first place
18:51:06 <abadger1999> nirik: I think that would be fine according to the current policy as it would merely be current fesco deciding that woould be its criteria for selecting someone to ask to fill the seat.
18:51:16 <adamw> sgallagh: that does tend to be the only time people really think about rarely-invoked items of policy, though.
18:51:18 <dgilmore> http://fedoraproject.org/wiki/FESCo_election_policy#Schedule says elections are twice a year
18:51:19 <nirik> https://admin.fedoraproject.org/voting/results/fesco-f20 would be jwb and kalev
18:51:20 <t8m> sgallagh, +1
18:51:21 <sgallagh> abadger1999: That's a fair statemetn
18:51:27 <dgilmore> not tied to releases
18:51:37 <abadger1999> nirik: I'm not sure it's the right choice, but it's not a problematic choice :-)
18:51:46 <dgilmore> it just happens that normally releases and twice yearly elections go hand in hand
18:51:47 <pjones> dgilmore: indeed it does.
18:52:32 <dgilmore> so i think starting the election process is what we should do
18:53:02 <dgilmore> proposal: start the election process for the N-1 seats
18:53:03 <abadger1999> I am -1 to starting the full election process.
18:53:13 <dgilmore> abadger1999: why?
18:53:13 <abadger1999> Neutral on whether to do an election for just one seat.
18:53:32 <dgilmore> abadger1999: our policy states twice yearly elections
18:53:37 <abadger1999> dgilmore: I really do not think that potentially replacing half of fesco midway through a release is a good idea.
18:53:42 <pjones> Given the schedule does in fact say time, let me say that I question the legitimacy of /my/ FESCo seat.
18:53:45 <sgallagh> dgilmore: " as part of the Fedora Project combined election process"
18:54:02 <sgallagh> So if we hold elections, so too must the Board, the Ambassadors...
18:54:04 <abadger1999> dgilmore: however, in the past when we've slipped we've always slipped the elections to match releases as well.
18:54:06 <dgilmore> sgallagh: so we go to the board and get things moving
18:54:20 <dgilmore> abadger1999: then the policy needs updated
18:54:57 <sgallagh> I'm fine with us voting to make changes to the policy, provided that they take effect *after* the next regular election.
18:54:58 <abadger1999> dgilmore: Including, this tine... where we asked the board and they agreed to extend and (I believe) voted on it ourselves?
18:55:05 <sgallagh> I agree, the current policy is bad.
18:55:21 <mattdm> sooooo. this was brougt to the Fedora Project Board in specific back in march.
18:55:27 <sgallagh> I just don't like the precedent that we can change election policy at any time that suits us
18:55:36 <pjones> sgallagh: you keep saying "next regular election", but one of the problems here is that we simply don't have those right now.
18:55:42 <jwb> sgallagh, you can't, and didn't.
18:55:59 <sgallagh> jwb: Can't and didn't what?
18:56:13 <jwb> sgallagh, change the policy.  fesco asked the board for an extension and it was granted.
18:56:21 * nirik notes as a side note there's a future governance thing scheduled for flock.
18:56:30 <adamw> jwb: i think he's talking about the idea of holding a snap election now instead of appointing a membert.
18:56:49 <jwb> ah
18:57:02 <sgallagh> jwb makes a good point though, I think the Board has to ratify any change in our election process anyway
18:57:17 <abadger1999> adamw, jwb: we're mixing both of those together...
18:57:44 <t8m> I do not think having irregular one member election makes a sense just now.
18:57:47 <abadger1999> pjones is asking that we have an election now for the half of fesco that's in the extension period, I think.
18:57:54 <sgallagh> jwb: Right, I'm just sticking to my stance that we must be required to follow our own rules. If we think they need changing, that change should be deferred so as not to present the appearance of impropriety.
18:57:55 <mattdm> the "snap election" for _one_ vacancy is easy -- it's simply the process by which FESCo might decide to select "community members they think would do a good job"
18:57:58 <abadger1999> and additionally we have to decide how to fill my seat.
18:58:18 <t8m> Given the shortened term I'd really prefer to either appoint someone directly or keeping the seat empty
18:58:58 <nirik> so, if we don't do elections now, the next ones would be after f21 release right?
18:59:06 <jwb> fesco policy says seats are filled based on the runners up of the last elections.  nirik already pointed out who those people were
18:59:09 <mattdm> nirik yes indeed.
18:59:17 <jwb> so i'm confused why there's a question on how to fill seats?
18:59:20 <abadger1999> jwb: no
18:59:26 <mattdm> jwb it technically says "last election". we went through those two already.
18:59:30 <adamw> sgallagh: afaics, none of that is really written down anywhere. none of the fesco policy pages actually define how the policy itself is set, who's responsible for setting it, the derivation of authority...none of that.
18:59:31 <abadger1999> jwb: Those are the runners up of the election before the last one.
18:59:50 <jwb> ah, i see
19:00:07 <nirik> The election policy came out of the old FESCo... fedora extras steering comittee. ;)
19:00:41 <abadger1999> Yeah... It's first 24 months of fedora old.
19:01:12 <jwb> i think pjones just said the extension is now making him feel a bit of illegitimacy about his seat.  that seams concerning too
19:01:42 <sgallagh> That extension was made by a Board ruling, which *should* legitimize it.
19:01:49 <abadger1999> So another option would be everyone who wants their seat re-voted could resign and then they could rerun in the special election.
19:02:00 <mattdm> jwb that *is* why we asked the board rather than just declaring ourselves to have a longer term. I felt weird about that too.
19:02:13 <jwb> sgallagh, maybe pjones disagrees.  if so, it could lead to another resignation
19:02:17 <jwb> pjones, ?
19:02:45 <sgallagh> Yeah, I wouldn't have been comfortable with us declaring that extension unilaterally either
19:02:55 <abadger1999> that removes the "I feel illegitimate" but doesn't do anything about "I feel you are illegitimate".
19:03:02 <pjones> abadger1999: but think that through.  Let's say I did that.  And then we didn't hold an election, because of whatever reason.  At that point a majority vote in a meeting with quorum fulfilled could be comprised mostly of people who weren't elected.
19:03:04 <pjones> That's bad.
19:03:32 <abadger1999> pjones: Well -- I'd tie that into "We need to hold a special election to fill abadger1999's seat"
19:03:45 <pjones> (it's not as bad as the whole majority being unelected mind you, but it's quite concerning.)
19:04:19 <nirik> proposal: offer abadger1999's seat to jwb then kalev (as runner ups in the previous election)
19:04:37 * pjones still -1
19:04:46 <nirik> ok
19:05:02 <nirik> pjones: because you feel there should be a new election or?
19:05:07 <pjones> yes.
19:05:10 <sgallagh> I'm -1, but only because it disagrees with our established policy, not because I have a problem with either candidate
19:05:10 <pjones> FWIW if we did hold a full election, I'd also be inclined not to run again.
19:05:11 * abadger1999 would like to reach consensus but in the end would vote +1 to nirik's proposal
19:05:30 <abadger1999> or to offering to another fesco selected candidate, etc.
19:05:51 <nirik> abadger1999: would you be willing to just stay until f21? ;)
19:06:06 <sgallagh> nirik: If you want to propose one of those candidates as a recommendation under rule 2) directly, that's cool :)
19:06:30 * nirik looks at the rule 2) again
19:06:45 <sgallagh> Basically "FESCo asks whomever we think would do a good job"
19:06:53 <dgilmore> http://fedoraproject.org/wiki/FESCo_election_policy#Filling_Vacant_Seats
19:07:01 <sgallagh> For the record:
19:07:02 <nirik> well, thats not actually what it says.
19:07:09 <nirik> It says fesco will ask the community.
19:07:10 <dgilmore> rule 2 gives the option to pick someone
19:07:14 <sgallagh> Proposal: Ask adamw to fill the seat
19:07:23 * nirik reparses perhaps I failed there.
19:07:25 <sgallagh> "FESCo will ask Fedora community members that they think would do a good job"
19:07:43 <abadger1999> yeah, sgallagh has the correct interpretation :-)
19:07:43 <nirik> ok thats just hard to read.
19:07:47 <nirik> but I agree.
19:08:08 <t8m> nirik, +1
19:08:27 <dgilmore> nirik: "FESCo will ask Fedora community members who they think would do a good job" is how i guess you read it first
19:08:33 <pjones> I concur about your reading of the phrase.  I think we're doing this instead of holding an election we should have held.  I don't like it.
19:08:34 <abadger1999> nirik: for staying until f21... I'd prefer not to... and perhaps the can of worms has already been opened?
19:08:36 <nirik> dgilmore: yeah.
19:09:06 <dgilmore> proposal: ask the board to start the eleections process
19:09:06 <sgallagh> pjones: FWIW, abadger1999 would not have been up for re-election in any case.
19:09:30 <t8m> dgilmore, +1 or whatever to end the meeting today :D
19:09:33 <dgilmore> sgallagh: right but nottings seat is so kyle will be up for election when we do have them
19:09:40 <t8m> I think we are going in circles
19:09:54 <sgallagh> Proposal: at this point, move to rule 3)?
19:09:57 <nirik> t8m: yeah, since abadger1999 isn't stepping down today, perhaps we can ponder on this a bit more?
19:10:04 <sgallagh> "If the open seats are still not filled, FESCo will operate with less members until the next FESCo election"
19:10:32 <dgilmore> sgallagh: that would make an additional seat open next election but sure
19:10:35 <abadger1999> sgallagh: I'd also be +1 to your candidate proposal but similarly would prefer something that tried to address some of pjones' concerns.
19:10:45 * dgilmore can't remeber if the next one is 4 or 5 seats
19:10:48 <pjones> And again I don't feel that's legitimate, since we've skipped having an election we should have had.
19:11:21 <dgilmore> pjones: fair concern
19:11:23 <adamw> pjones: so...do you consider the board doesn't have authority to extend the term of a fesco membership?
19:11:25 <nirik> it's 5.
19:11:32 <dgilmore> I think at this point we need to go to the board
19:11:47 <abadger1999> dgilmore: We've already been to the board...
19:11:50 <pjones> adamw: I think they shouldn't have.
19:11:56 <dgilmore> abadger1999: well we need to go again
19:12:13 <abadger1999> sure... but maybe we should have a different question to ask them then ;-)
19:13:01 <t8m> Board, please solve our problems with resigning members somehow. :)
19:13:19 <adamw> to make a respectful suggestion...i think the cogent question could be "please come up with a much clearer codification of who is responsible for setting FESCo's policies, and how they may be changed."
19:13:38 <pjones> I will certainly say that in... what was it, March?  when we moved the election to begin with, I'd have argued more strongly about it if either a) I'd realized we'd have so many resignations, or b) I'd realized what our backfill policy was.
19:13:49 <adamw> afaics there's just no clarity at present about who is actually responsible for setting fesco's membership policy - the board, or fesco - and how it can be changed.
19:13:50 <mattdm> adamw "setting FESCo's term and election policies"?
19:14:04 <pjones> adamw: that's true.
19:14:10 <nirik> adamw: in the past fesco did actually. ;)
19:14:13 <mattdm> pjones thanks that helps me understand where you're coming from.
19:14:13 <abadger1999> adamw: <nod> -- when the policy was writtedn, the board didn't exist I think.
19:14:20 <adamw> mattdm: yeah...i guess the scope is 'the policies that people think fesco may not have inherent authority to set'.
19:14:58 <adamw> policies that are just relating to how fesco discharges its own responsibilities are obviously up to fesco to decide...so i guess the issue here is policies to do with how fesco is actually constituted?
19:15:12 <nirik> pjones: I think we moved / decided no election back in jan or even late last year.
19:15:14 <mattdm> pjones But given that, isn't holding an election for the backfill rather than just appointing a mitigating factor for your "b"
19:15:27 <pjones> nirik: yeah, I think somebody above said "march" and I can't quite figure out when it was.
19:15:44 <mattdm> pjones uh it was me because I looked at the board ticket and that's when it is dated
19:15:49 <nirik> I think it was early in the next stuff where we decided that f21 wouldn't be on 'normal' schedule
19:15:50 <adamw> the idea that fesco's authority derives from the board and that the board should have some say in fesco's constitution is reasonable, but afaics is not actually codified anywhere.
19:16:05 <nirik> mattdm: thats when it was filed?
19:16:09 <abadger1999> adamw: <nod> also because fesco pre-dates the Board :-)
19:16:09 <pjones> adamw: yeah, and I don't think it's really the ase.
19:16:10 <pjones> case
19:16:21 <mattdm> nirik so says trac. but I also remember it being earlier
19:16:53 <pjones> So regardless of the history of when that was... mattdm, you just asked me a question and I can't figure out by reading it what it was.
19:17:19 <sgallagh> pjones: "b) I'd realized what our backfill policy was."
19:17:38 <pjones> I know what I wrote.
19:17:46 <adamw> pjones: so, you'd go for a model where fesco's existence and authority is kind of independent of the board, and it's responsible for its own constitution?
19:17:57 <mattdm> pjones sorry I'll rephrase :)
19:18:10 <pjones> adamw: I think we may be off on a tangent?
19:18:11 <abadger1999> I think sgallagh is asking whether having an election for vacant seats is a reasonable compromise for you.
19:18:32 <adamw> pjones: yeah, you're right, sorry - not exactly a tangent, but i think i made the point that it needs deciding and clearly stating one way or the other, so i'll shut up now
19:18:37 <pjones> abadger1999: I think it could be, ... maybe?
19:18:45 <nirik> adamw: see mention of governance thing at flock. ;)
19:18:52 <pjones> adamw: I think you're right, and it does, and that's not going to happen in this meeting :)
19:18:58 <pjones> adamw: and I'll happily help out at flock ;)
19:18:59 <mattdm> pjones you said that you would have argued more strongly for time-based terms rather than release-based ones if you'd realized the backfill policy. but if we hold an election for backfill rather than appointing, isn't that better?
19:19:41 <pjones> mattdm: no, I said I'd have argued strongly not to delay the election.  Our policy says we have time based terms, and though (somewhat ambiguous) process we rescheduled some of that timeframe, AFAICS, as a one-shot deal.
19:19:43 <abadger1999> Proposal: Fesco to hold a special election to fill one or more vacant seats (abadger1999, maybe others).  Terms will last until that seat would normally be re-voted.
19:20:12 <nirik> sure, +1
19:20:14 <pjones> mattdm: I do think holding an election for backfill /might/ be better.
19:20:27 <pjones> abadger1999: +1 I think.
19:20:31 * sgallagh 0
19:20:38 <abadger1999> +1 then
19:20:49 <t8m> +0 I think it is completely unnecessary
19:21:24 <mattdm> abadger1999 sure +1
19:22:26 <abadger1999> t8m: I think it's unnecessary but doesn't violate policy or expectation and satisfies more people .  So I think it's a good compromise.
19:22:40 <abadger1999> Need one more to pass.
19:23:04 <dgilmore> +1 for backfilling abadger1999's seat by election
19:23:07 * nirik is with abadger1999
19:23:24 <nirik> so, when would it open to nominations, when to voting and when close?
19:23:43 <sgallagh> How long will it take to retool the election app?
19:23:46 <pjones> and possibly the unfortunate question: do we need to ask the board for that?
19:24:15 <dgilmore> nirik: announce immediate open for nominations
19:24:44 <nirik> sgallagh: retool? it should be ready unless we wanted to change the voting method or something?
19:24:47 <sgallagh> How many seats are we filling? Just abadger1999's or is pjones resigning as indicated above?
19:24:47 <abadger1999> pjones: Unless you have an objection I think it would fall under "FESCo will ask Fedora community members that they think would do a good job" --> just htat fesco has chosen an election as the method of determining this.
19:24:50 <pjones> In order to remain consistent with the positions I stated above, please include my seat as open.
19:24:57 <pjones> abadger1999: fair
19:25:05 <sgallagh> nirik: I thought I remembered it took some time to get set up. Maybe I am mistaken
19:25:28 <sgallagh> abadger1999: I'm on board with that interpretation
19:26:03 <abadger1999> sgallagh: no more than a few hours.
19:26:41 <mattdm> hours??? ouch
19:26:59 <sgallagh> mattdm: That's for the voting system setup, not the nomination period :)
19:27:08 <abadger1999> Coordination is what usually takes up that time. (someone with permissions to create the election getting the proper information about seats, candidates, blurb on the election, start end dates, etc)
19:27:42 <mattdm> In any case, if we _are_ doing an election, I'd like to see more publicity and participation then we've had in the past few elections
19:27:51 <pjones> mattdm: oh god yes
19:27:56 <dgilmore> pjones: so yours and abadger1999's seat so we need to fill two seats?
19:28:19 <pjones> dgilmore: that appears correct to me at this point.  Unless any of the other N-1 people have concerns similar to mine.
19:29:38 <abadger1999> #info Fesco to hold a special election to fill one or more vacant seats (abadger1999, maybe others).  Terms will last until that seat would normally be re-voted. PASSED (+1:5, 0:2, -1:0)
19:29:58 <abadger1999> #info Also filling pjones's seat
19:31:46 <mattdm> I think we did the right thing in taking the question to the board earlier. *shrug*
19:32:44 <sgallagh> mattdm: Mind announcing the nomination period with your FPL hat on?
19:32:51 <pjones> mattdm: maybe we'll have to discuss that with more beer in hand sometime.
19:33:21 * nirik is happy to enter the election info and start it whenever, etc.
19:33:31 <randomuser> hey, isn't notting's seat open too? it seems inconsistent to nominate there and hold elections for the other
19:33:39 <mattdm> pjones absolutely.
19:33:52 <abadger1999> randomuser: That one was filled according to policy
19:34:03 <randomuser> fair enough
19:34:04 <pjones> randomuser: his was actually filled last week.  While I wish that hadn't been done so quickly, I'm not going to fight to undo it.
19:34:29 <mattdm> randomuser also, that one was filled with a runner-up from the previous election. so.... it's at least a little different
19:34:48 <pjones> yeah, it appears to have actually followed the policy /as written/.
19:34:59 <randomuser> I missed that it had been filled, and now feel a little silly mentioning it. Carry on :)
19:35:09 <pjones> No worries, thanks for bringing it up to be sure.
19:35:14 <dgilmore> :)
19:35:14 <mattdm> ++
19:35:36 <sgallagh> Ok, are we about done for today, then?
19:36:02 <pjones> Do we want to discuss how to promote this election better than past ones?  Should we do that on the (a) mailing list instead?
19:36:08 <mattdm> sgallagh I can do the announcing. do we have this go through the normal elections wrangler? there's some process to figure out :)
19:36:09 <pjones> (hint: yes and yes)
19:36:21 <mattdm> pjones +1 and +1
19:36:39 <sgallagh> pjones: Fine with me on both counts
19:36:49 <mattdm> pjones possibly the board-discuss mailing list?
19:37:03 <abadger1999> pjones: +(1, 1)
19:37:23 <pjones> mattdm: sounds good to me, fearless leader.
19:37:43 <sgallagh> Though I'll chuckle a bit if we end up with a higher voter turnout and candidate pool than in a standard election :-P
19:37:43 <mattdm> pjones: oh god, now I _am_ scared.
19:37:48 <pjones> It'd be good if we could get a better turnout than the percentage of people who voted against Putin in Russia's last election.
19:38:15 <pjones> sgallagh: I think that would be *splended*.
19:38:28 <sgallagh> Can we get a "Voted in a Special Election" Badge as a sweetener?
19:38:40 <pjones> mailing list
19:38:44 <sgallagh> Right.
19:38:53 <sgallagh> Please CC those of us not on the Board?
19:39:05 <pjones> I thought board-discuss was the public one?
19:39:06 <mattdm> board-discuss is public
19:39:09 <sgallagh> Ah, ok.
19:39:14 * sgallagh goes to subscribe to *another* list
19:39:17 <mattdm> this should absolutely go on the public board
19:39:31 <mattdm> sgallagh if you were on advisory-board, it's the same thing
19:40:32 <sgallagh> Alright, can I close out this meeting now?
19:40:38 <pjones> yes.
19:40:44 <dgilmore> sgallagh: si senor
19:41:04 <sgallagh> Thanks for an interesting meeting, folks!
19:41:06 <sgallagh> #endmeeting