20:00:08 <stevebaker> #startmeeting heat
20:00:09 <openstack> Meeting started Wed Dec 11 20:00:08 2013 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:13 <openstack> The meeting name has been set to 'heat'
20:00:19 <stevebaker> #topic rollcall
20:00:25 <shardy> o/
20:00:26 <bgorski> o/
20:00:28 <randallburt> o/
20:00:30 <tims> o/
20:00:32 <arbylee> o/
20:00:36 <andersonvom> o/
20:00:52 <spzala> hi
20:00:54 <stevebaker> dolphm: ping heat meeting
20:00:58 <sdake_> o/
20:00:59 <SpamapS> ~o~
20:01:04 <dolphm> \o/
20:01:04 <lakshmi> o/
20:01:12 <asalkeld> o/
20:01:18 <pshchelo> \o/
20:01:25 <zaneb> it's bizarre having this meeting in the middle of the day
20:01:35 <sdake_> are you in the us now zane?
20:01:41 <stevebaker> zaneb: close the curtains
20:01:50 <pshchelo> no less bizzare at 10 pm
20:02:06 <zaneb> pshchelo: no, 10pm is normal for me
20:02:09 <stevebaker> #topic Adding items to the agenda
20:02:23 <stevebaker> https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:02:53 <stevebaker> should we talk heat-core nomination? that seems to be the vigorous discussion of the week
20:03:07 <skraynev_> hello all
20:03:17 <kebray> \o
20:03:29 <sdake_> might as well stevebaker
20:04:49 <stevebaker> shardy: if/when dolphm show up we can talk management-api dependencies
20:05:00 <asalkeld> I think we should at least periodically check to see if we need add/remove people
20:05:05 <dolphm> stevebaker: o/
20:05:11 <shardy> stevebaker: Ok, did I miss a discussion on that?
20:05:25 <stevebaker> specifically https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
20:05:32 <shardy> I thought we were going to use normal policy rules until the service scoped token stuff gets worked out
20:05:33 <stevebaker> #topic management-api dependencies
20:05:51 <zaneb> asalkeld: it's supposed to be reviewed once per cycle. we should be looking to add people more often than that though, I agree
20:06:02 <shardy> stevebaker: I got blocked on bug #1256983 but we're merging that now
20:06:05 <uvirtbot> Launchpad bug 1256983 in heat/havana "[OSSA 2013-035] Heat ReST API doesn't respect tenant scoping (CVE-2013-6428)" [Critical,In progress] https://launchpad.net/bugs/1256983
20:06:28 <stevebaker> shardy: that is what I thought too, but https://blueprints.launchpad.net/heat/+spec/management-api has https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition as a dependency. It looks like we can remove that
20:06:32 <shardy> dolphm: How is the service scoped role stuff going, still in discussion AFAICT?
20:07:02 <shardy> stevebaker: Ok, I think maybe I added that when we were working out the options
20:07:18 <dolphm> shardy: yes. as always, there's several proposed solutions with contention among them
20:07:28 <stevebaker> lol
20:07:48 <shardy> dolphm: Ok, so we shouldn't be blocking on it then, maybe plan to migrate to it for K?
20:08:07 <dolphm> shardy: ++ definitely shouldn't be a blocker from developing new APIs
20:08:09 <shardy> dolphm: and use a policy rule which overrides the default scoping for Icehouse?
20:08:28 <dolphm> shardy: i don't follow the question?
20:09:05 <dolphm> shardy: if you want to be super-safe, i'd suggest publishing a policy for new APIs that simply deny all access, forcing deployers to utilize keystone broken approach, or wait for a better solution from keystone
20:09:12 <shardy> dolphm: I'm just explaining my proposed workaround, which is to define an "is service admin" policy rule, which enables a user to e.g list all stacks for all tenants
20:09:35 <shardy> that might be "heat_admin" role in the "admin" tenant or somehting, configurable in the policy
20:09:48 <dolphm> shardy: ++
20:09:55 <shardy> dolphm: Ok, cool, thanks
20:10:33 <stevebaker> right
20:10:35 <shardy> stevebaker: Ok, so I can make progress on this now, as soon as https://review.openstack.org/#/c/61455/ lands
20:10:42 <dolphm> shardy: i definitely encourage service-specific admin-style roles... nothing in policy prevents you from requiring such arbitrary roles
20:10:42 <stevebaker> #topic Unassigned icehouse-2 blueprints
20:11:25 <stevebaker> #link https://launchpad.net/heat/+milestone/icehouse-2
20:12:03 <stevebaker> if you sort by assignee you'll see 7 unassigned bps for i-2
20:13:06 <stevebaker> if there are no takers they will just be kicked to i-3 at some point
20:13:13 <shardy> and a critical unassigned bug, is that really critical sdake_ ?
20:13:28 <shardy> I'd say "high" myself
20:13:32 <zaneb> https://blueprints.launchpad.net/heat/+spec/parameter-nested-schema <- maybe tspatzier wants that one? he is away atm but has been working on related stuff
20:13:52 <sdake_> shardy seems like a security issue but if you want to make high thats fine with me
20:14:26 <stevebaker> zaneb: we should wait until his return
20:14:37 <SpamapS> Critical, to me, is "Heat's mission is compromised entirely by this bug."
20:15:00 <sdake_> ya, when i see security problems, i see them as critical
20:15:01 <shardy> sdake_: If it's critical, someone needs to take it, but IMO it's not critical, as there are several workarounds, e.g re-enable selinux in the userdata
20:15:06 <sdake_> so we have different defintions ;0
20:15:08 <stevebaker> asalkeld: is this a dupe of what has already been implemented? https://blueprints.launchpad.net/heat/+spec/notification-support
20:15:16 <asalkeld> yeah
20:15:17 <sdake_> shardy i'll change the prioirty
20:15:38 <stevebaker> to me, critical is heat is completely broken
20:15:40 <randallburt> oh whoops. I just grabbed that one stevebaker asalkeld
20:15:45 <shardy> stevebaker: +1
20:15:52 <stevebaker> if it is an actual security bug it should be flagged as such
20:15:55 <sdake_> cves are always critical in the bug tracker
20:15:56 <randallburt> but if the works already done...
20:16:05 <SpamapS> sdake_: security is orthogonal to importance.
20:16:21 <sdake_> bug already changed to high stop beating up on me please ;)
20:16:34 <SpamapS> I mean to clarify for all, not beat on you.
20:16:44 <stevebaker> but I'm wondering, should it be flagged as security?
20:17:00 <sdake_> i dont think it should be flagged as security - since the vms don't work atall with selinux enabled ;)
20:17:16 <stevebaker> ok, fair enough
20:17:24 <sdake_> hard to have a security bug if it doesn't allow a vector of attack :)
20:17:48 <SpamapS> sdake_: not working at all == 0 risk == security wins: fatality!
20:18:19 <asalkeld> I think we need a bp for migrating to oslo.messaging ?
20:18:36 <sdake_> asalkeld +1
20:18:53 <stevebaker> #action asalkeld to raise a bp for migrating to oslo.messaging
20:19:04 <SpamapS> bp?
20:19:08 <SpamapS> that's a bug IMO
20:19:26 <SpamapS> Continuing to use oslo-incubator stuff that has a real library is a bug.
20:19:33 <stevebaker> I don't think it matters, just something to track it
20:19:36 <zaneb> SpamapS: the distinction is as spurious as ever
20:19:50 <stevebaker> #topic Repurposing of the stack/resource status columns - related to stack convergence
20:19:53 <SpamapS> bps have specs. That's the distinction.
20:19:58 <shardy> The advantage of bugs is they are allowable as backports to stable..
20:19:58 <stevebaker> #link https://blueprints.launchpad.net/heat/+spec/stack-convergence
20:20:07 <shardy> something to bear in mind when deciding which to choose ;)
20:20:13 <sdake_> we don't want to  backport oslo.messaging into stable!
20:20:18 <stevebaker> andersonvom: want to take this one?
20:20:24 <andersonvom> stevebaker: sure
20:20:39 <shardy> sdake_: I'm not saying we do, just in general, consider if you might want to when deciding bp vs bug
20:21:00 <sdake_> shardy ya that makes sense - just going off your original cue ;0
20:21:08 <andersonvom> so, the problem there is that when retrieving the current status of all resources, the 'status' attributes of stack and resources become ambiguous
20:21:29 <andersonvom> and we end up having no proper place to store that information
20:21:39 <asalkeld> SpamapS, i prefer bugs over bp too, but just too late (made the bp)
20:21:49 <zaneb> andersonvom: ambiguous in what way?
20:22:16 <SpamapS> asalkeld: thats the other distinction.. "it was already done one of the two spurious ways. ;)"
20:22:17 <andersonvom> zaneb: the current 'status' attributes of stack/resource is really in reference to the action, not the objects themselves
20:22:57 <shardy> andersonvom: The stack status relates to the state of the stack, each resource has it's own status, which you're updating
20:22:57 <SpamapS> andersonvom: why would we want to store the status that is already in the external resource?
20:23:09 <SpamapS> andersonvom: it is out of date the moment we store it.
20:23:12 <shardy> the combination of which might change the stack status (not action)
20:23:23 <asalkeld> is there a way to delete a bp?
20:23:42 <zaneb> so, 'status' is that status of the last action
20:23:49 <zaneb> s/that/the/
20:24:09 <andersonvom> shardy: true. but a similar problem happens there as well: after I complete all the syncing, the action completes, but we have no way of telling what the current stack "health" is
20:24:14 <stevebaker> asalkeld: Definition -> Obsolete and remove the Milestone target
20:24:19 <andersonvom> zaneb: yes!
20:24:22 <zaneb> I'm not clear what the issue is with that though
20:24:46 * zaneb is way behind on ML posts, sorry :(
20:25:00 <shardy> Yeah, so if we allow e.g heat stack-update --check, the result would be UPDATE, FAILED if any resources are polled and found to be in a FAILED state
20:25:16 <randallburt> asalkeld, stevebaker I superseded the duplicate notifications bp if that's what you're looking to do.
20:25:25 <asalkeld> sure
20:25:51 <shardy> andersonvom: I agree we *could* separate the last lifecycle action status from the last polled status, but I'm not sure what that gains us, if the polling is user initiated
20:25:52 <stevebaker> randallburt: so did I ;)
20:26:08 <randallburt> double superseded!
20:26:30 <stevebaker> like betamax
20:26:32 <andersonvom> shardy: we may want to have a background task constantly updating the stacks, for example
20:26:51 <andersonvom> shardy: that way, it would be easy to spot when something fails
20:26:57 <shardy> andersonvom: Ok, then you keep triggering an update and look for the result of that update
20:27:04 <SpamapS> I do like the idea of a background updater that can be optimized using notifications.
20:27:16 <shardy> andersonvom: The result is still either COMPLETE or FAILED
20:27:35 <SpamapS> But that info is _extremely_ different from the status of the actions requested by the user.
20:27:37 <randallburt> andersonvom:  yuck. I would prefer this be part of the stack owner's monitoring tbh. we've had hard times with bg threads and it gets worse now that multi-engine is landing
20:28:03 <stevebaker> landed
20:28:09 <randallburt> yup.
20:28:27 <randallburt> jasond makes progress even when he's on vacation ;)
20:28:40 <zaneb> shardy++, randallburt++++++
20:28:46 <shardy> randallburt: +1
20:29:12 <stevebaker> so what is the resolution to this topic?
20:29:12 <shardy> But there is still a valid use case for the check-update, which is not continuous monitoring
20:29:22 <shardy> it's to figure out what will happen if you do a converge
20:29:23 <arbylee> shardy: If you run a stack update, it feels odd to see a stack's state as UPDATE_FAILED, when it successfully performed it's action.  An update was called and the latest resource status was retrieved and stored
20:29:29 <randallburt> to be clear, though. I got no issue with an api method that says "check the status of the things and update stack state as a result"
20:29:53 <randallburt> shardy:  yes, that.
20:30:03 <shardy> arbylee: Ok, so maybe you have a new action called "CHECK", or something?
20:30:17 <shardy> arbylee: what you call the action doesn't really matter, its the status you're interested in
20:30:21 <randallburt> my suggestion was to add a STATE attribute to resources and do "something better" in the v2 api
20:30:43 <SpamapS> hrm
20:30:45 <shardy> randallburt: So have state and status?  That seems confusing
20:30:56 <andersonvom> shardy: I guess what arbylee is saying is that it becomes ambiguous in a sense that an actual failure of the action will also be represented as FAILED
20:31:09 <SpamapS> So I think background threads have been painted in a bad light for no good reason.
20:31:25 <arbylee> shardy: right, but the status column still seems to represent the status of the ACTION.  If I see CHECK_FAILED, or any other verb here, it's ambiguous whether the call itself failed, or a resource is down
20:31:35 <randallburt> shardy:  well, kinda. to me, status was "how did the last operation go" and state would be a stop gap, so if, for v1 we just update status then I'm not too fussed as long as its documented.
20:31:42 <zaneb> randallburt: that name would be problematic
20:31:52 <shardy> SpamapS: because they've regularly bitten us with horrible eventlet related bugs?
20:32:13 <SpamapS> shardy: that is a bug, yes. But there are really solid answers to that kind of problem.
20:32:14 <randallburt> zaneb:  sure, just and example.
20:32:42 <randallburt> could be called "FOO", but the gist is that I think we need to separate operational status from downstream resource state in v2
20:32:43 <SpamapS> Like having the "stack crawler" just be a client.
20:32:44 <stevebaker> would this issue all go away if we just make check and converge part of the same action?
20:33:05 <SpamapS> A client that subscribes to notifications from external sources that have such things available, and otherwise polls.
20:33:05 <shardy> randallburt: I think nova does the opposite?  They have Status, then several States related to Task/Power
20:33:19 <zaneb> SpamapS: if the engine has multiple background threads then it needs to be scaled out differently. If we have to do that, we should either do it in a different binary or, preferably, punt it to something external
20:33:24 <randallburt> stevebaker:  iIRC we discussed that a bit at the summit, but it was generally agreed that I wanted to be able to see state without converging
20:33:37 <SpamapS> zaneb: yes I am saying do it in a different binary. But don't punt it.
20:33:57 <randallburt> s/I/we
20:34:02 <SpamapS> also it is worth looking at what Curvature does
20:34:12 <SpamapS> though I suspect that just updates on user demand
20:34:30 <arbylee> stevebaker: do you mean to only have a converge call?  What would trigger someone to call this action?  I saw check/sync as the indicator that a converge needs to occur
20:34:35 <andersonvom> stevebaker: that may not be ideal since the user may not want to "fix" the stack immediately. or, in the case of bg proc, it may not be good to do converge it automatically
20:35:03 <andersonvom> s/do converge/converge/
20:35:19 <SpamapS> So what if check is external and we have a place for external things to annotate resources?
20:35:30 <SpamapS> Because "converge" is going to go and poll reality anyway.
20:35:32 <shardy> andersonvom: But why is it bad for a stack to go into a FAILED state, then be converged into COMPLETE again whenever the user chooses?
20:35:36 <tims> SpamapS I would highly suspect Curvature just updates on user demand
20:36:18 <andersonvom> shardy: I think that's what we want to do, right? ;)
20:36:54 <SpamapS> COMPLETE is a misnomer if there isn't an action to COMPLETE. Something else like STEADY would be more accurate.
20:37:04 <randallburt> andersonvom, shardy yes, I think that's what we want to do, but this first step is letting me see if the stack and reality are different. I want the ability to know that and then *optionally* converge.
20:37:06 <shardy> andersonvom: I'm saying I'm still not clear on why we need state and status
20:37:09 <andersonvom> shardy: the only "problem" with failing a check (or whatever action) is that we will never know if the action itself failed, or just the resource was down or in an innapropriate state
20:37:42 <shardy> When andersonvom Yes you do, by looking at the resource states, and by the reason provided
20:37:48 <randallburt> andersonvom:  and for the v1 api, I think we can just use status and say "the last operation doesn't reflect reality anymore"
20:37:51 <shardy> s/^When//
20:37:59 <SpamapS> shardy: I agree with Anderson. There is an action which we want to know the outcome of, and an overall resource status which has an entirely different set of data associated (like how fresh is that perceived status?)
20:38:31 <shardy> SpamapS: But it's the exact same data we use when declaring the outcome of a resource action
20:38:37 <shardy> e.g check_create_complete
20:38:44 <shardy> we'll be polling the exact same thing
20:38:52 <randallburt> SpamapS:  +1 but dunno if we *have* to do that now, rather than get what we want within the confines of v1 and then expand that in v2
20:38:56 <SpamapS> shardy: it is the same data, but at a different time and in a different context.
20:39:02 <tims> andersonvom: would there be different states possible more granular than "failed"?
20:39:27 <andersonvom> tims: possibly. we may want to point out that a resource is misconfigured, for instance
20:39:35 <shardy> SpamapS: That's why I'm saying, if it's user initiated, it's in the context of the most recent user initiated action, which is to trigger syncing the world's state with the stack
20:39:38 <randallburt> s/what we want/something reasonably effective for the use case
20:40:04 <randallburt> shardy:  so the proposal is (CHECK, FAILED)?
20:40:07 <SpamapS> shardy: that makes sense, I agree they are only slightly different at any one time.
20:40:22 <zaneb> so wouldn't the check call just poll everything and return its results? why are we talking about having to store this in the DB where the state usually goes?
20:40:23 <shardy> I guess it doesn't matter that much either way, but won't it be confusing if a resource is UPDATE_COMPLETE_FAILED?
20:41:04 <shardy> randallburt: No I'm saying just update the stack without changing the definition, but triggering the check_update_complete logic, then set UPDATE_FAILED
20:41:12 <SpamapS> zaneb: I think it could work either way so we might want to try and fit it into use cases.
20:41:23 <shardy> randallburt: but if folks want the action named something other than update, fair enough
20:41:51 <shardy> All we are doing is updating, either the resource definition, state, or both
20:41:55 <andersonvom> shardy: I'm fine with using UPDATE, since that's what it really is
20:41:59 <SpamapS> There's also a problem in that if we store it in the DB, then we can't run checks concurrent with creates / updates
20:42:27 <shardy> SpamapS: IMO, that is a good thing ;)
20:42:37 <andersonvom> SpamapS: yes, but that's by design
20:42:52 <randallburt> I disagree its an UPDATE in the current semantics, but we're close so I won't fuss ;)
20:42:56 <shardy> SpamapS: Everything will be serialized by the stack lock anyway won't it?
20:43:07 <SpamapS> shardy: I have a user here at HP that spins up stacks that take 30 - 45 minutes to create.. it would be useful to start checking state before that completes.
20:43:22 <SpamapS> shardy: only if we need to change the stack.
20:43:40 <SpamapS> Otherwise let the DB present the consistent view of the stack to the check thread.
20:43:46 <zaneb> btw the way we report states ('<ACTION>_<STATUS>') in the v1 API sucks, and I'd be all in favour of augmenting it in v1 and replacing it in v2
20:43:58 <randallburt> zaneb:  ++
20:44:00 <stevebaker> can we wind this topic up and move on? Maybe carry on in #heat after the meeting
20:44:08 <randallburt> stevebaker:  good plan
20:44:12 <shardy> zaneb: +1
20:44:19 <zaneb> I blame cfn
20:44:24 <andersonvom> shardy zaneb SpamapS: so, do we all agree that it's going to be UPDATE_FAILED with the appropriate reason?
20:44:30 <SpamapS> I blame gnomes.
20:44:37 <shardy> Can people add the v2 API related suggestions to the wiki please?
20:44:41 <stevebaker> FOO_IN_PROGRESS is problematic in v1
20:44:42 <SpamapS> andersonvom: no, -> #heat post meeting. :-/
20:44:50 <stevebaker> #topic heat-core nomination
20:44:56 <shardy> https://wiki.openstack.org/wiki/Heat/Blueprints/V2API
20:45:24 <stevebaker> so I don't think we have a problem with evaluation criteria on who to nominate for core
20:45:37 <zaneb> next topic!
20:45:40 <shardy> ha
20:45:41 <zaneb> ;)
20:46:27 <stevebaker> but we do need to increase the core team size, and that seems to come down to motivating people to do reviews
20:47:03 <shardy> stevebaker: So, I agree re *our* criteria, but the point of my ML thread was to communicate those to people working hard on reviews hoping to become core
20:47:18 <shardy> I'd rather avoid a huge debate on that again now tho ;)
20:47:24 <zaneb> is the limiting factor really motivation?
20:47:40 <stevebaker> its a project-wide problem, people have many intrinsic and extrinsic motivators for doing reviews
20:48:05 <zaneb> getting up to speed with the whole codebase takes a long time and is really hard
20:48:19 <randallburt> so given that we've discussed the criteria on the ML, I suppose the next step is take those and start looking for folks that meet or are soon to meet them and start getting nominations together?
20:48:28 <zaneb> I think that slows us down much more than people not being motivated to do reviews
20:48:34 <SpamapS> Vote the way you want. We don't have to debate it really.
20:48:38 <stevebaker> zaneb: true
20:48:52 <zaneb> I think we're blessed with lots of really motivated contributors
20:49:41 <SpamapS> Jun Jie Nan btw, is my next suggestion for core.
20:49:45 <SpamapS> "nanjj"
20:49:47 <sdake_> I'd like to point out our current criteria; https://wiki.openstack.org/wiki/Heat/CoreTeam
20:49:54 <stevebaker> zaneb: btw you might want to make more of your +0 reviews -1 or +1. Apart from juking your stats, I often miss good comments from you because they are +0, not -1
20:50:24 <shardy> I think bgorski has been doing some excellent work too
20:50:32 <stevebaker> +1 on bgorski
20:50:56 <SpamapS> we can vote on ML, but just for sake of discussion, that's who I think will have the most positive impact
20:50:56 <zaneb> stevebaker: I like to bikeshed on the reviews, but I don't like to -1 unless there's a good reason
20:51:01 <shardy> nanjj has been doing a lot of reviews, but I'd like to see more non-cosmetic review comments
20:51:08 <randallburt> so nomination boils down to a ML post, yes? or do we need to discuss on IRC or something first?
20:51:21 <SpamapS> zaneb: yes please, +0 is actually specifically "the bikeshed score" ;)
20:51:30 <stevebaker> anyone in core can nominate anyone on the ML, then we vote
20:51:39 <bgorski> shardy, stevebaker thx but I know I still needs to work harder to become the core
20:51:44 <asalkeld> zaneb, +1 I like to leave comments with no +/- too
20:52:17 <zaneb> I actually feel like it would be better if 1 person were in charge of nominating, so they can co-ordinate feedback to prospective candidates
20:52:22 <randallburt> so to bring this around to the topic at hand, does the action item boil down to "do an evaluation based on our criteria and bring forth candidates"?
20:52:29 <zaneb> (PTL seems like the obvious choice for that)
20:52:32 <andersonvom> zaneb: +1 on not −1'ing without a good reason
20:52:48 <shardy> zaneb: I thought traditionally the PTL nominated, but I know anyone can if they want
20:53:10 <randallburt> and/or get in touch with folks who have potential and give them feedback
20:53:13 <stevebaker> anybody can, but I'll periodically review if anybody looks ready
20:53:15 <zaneb> shardy: well, we copied a wiki page from Nova that said anyone can do it
20:53:34 <stevebaker> and I am keeping an eye on it
20:53:52 <SpamapS> My take on -1's (and I'm sure you all already feel this) is that a) It can be taken back, b) it can be overridden, and c) it forces more action than +0. So if there is any inkling that a patch can be made better without inserting one's opnions (actual facts needed please) then I -1.
20:54:12 <shardy> zaneb: Yeah, but isn't that an openstack wide convention?
20:54:17 <SpamapS> very cautious not to -1 for just my opinion though.
20:54:31 <sdake> without a -1, nobody knows the patch needs more work when it may from the comments :)
20:54:40 <zaneb> so, e.g. if I think somebody is a good candidate for core but needs to work on a particular area, I'd like to contact the PTL and tell them that so they can give feedback if appropriate, or go ahead if they think my opinion is not important ;)
20:54:45 <shardy> zaneb: Seems like its good that any -core *could* nominate, but it may be more useful if nominally the PTL is the conduit
20:55:00 <randallburt> zaneb:  +1
20:55:06 <randallburt> shardy:  +1 as well
20:55:07 <zaneb> what I don't want to do is contact everybody in core and say 'let's nominate so-and-so, but not yet'
20:55:27 <sdake> our current mechanism is any core member can suggest a new core member -seems to work well so far
20:55:35 <zaneb> shardy: every project is free to define their own process
20:55:36 <SpamapS> I think holding a vote on somebody without discussing them with the rest of the dev community first (including that somebody) is also a mistake.
20:55:53 <randallburt> SpamapS:  very much so.
20:56:01 <SpamapS> So anyway, I think we all actually pretty much agree.
20:56:06 <asalkeld> yip
20:56:10 <SpamapS> Our criteria is a bit skewed, but that is o-k. Diverse opinions are a good thing.
20:56:11 <stevebaker> feel free to contact me privately so I can contact potential nominees.
20:56:17 <zaneb> ok, so let's say anyone in core can nominate, but they should talk to the PTL first?
20:56:21 <stevebaker> 4 minutes
20:56:26 <stevebaker> #topic open discussion
20:56:33 <sdake> well if thats the new process, change the wiki please
20:56:46 <sdake> alhtough my take is we don't need to single thread on the ptl
20:57:03 <stevebaker> you don't *have* to but you might want to
20:57:36 <stevebaker> -1 votes might offend the nominee ;)
20:58:11 <stevebaker> not that that has happened yet
20:58:11 <zaneb> if there are -1 votes the process is broken IMO
20:58:18 <shardy> stevebaker: That is one of the main reasons I wanted to more openly discuss criteria, I don't want to be the one saying -1 when someone is nominated
20:58:29 <sdake> typically I wouldn't expect a core member to suggest a new core that would get a -1 vote ;)
20:58:47 <stevebaker> its happened in other projects
20:59:05 <SpamapS> shardy: why not?
20:59:05 <zaneb> stevebaker: every one I've seen later reversed their vote
20:59:10 <shardy> I'd rather we align on what is expected, so we don't nominate folks who don't have consensus, and so folks who are candidates know what we expect
20:59:13 <SpamapS> shardy: I value your -1 very much. :)
20:59:33 <zaneb> SpamapS: -1 on adding folks to core is a veto
20:59:35 <randallburt> zaneb:  I disagree. The nomination shouldn't be a "formality" IMO. We should discuss candidates openly and if its −1, then why is it −1. That feedback is valuable.
20:59:51 <shardy> SpamapS: Because I would prefer folks to get +1'd an in to core, when they are ready, without any confrontation or hurt feelings
20:59:53 <SpamapS> right, none of us _wants_ to do that.
21:00:00 <sdake> well, the wiki should  be updated with whatever we want to use as a criteria - that way its written down and is a *commitment* to our criteria
21:00:03 <stevebaker> #endmeeting