20:02:17 <ttx> #startmeeting tc
20:02:17 <openstack> Meeting started Tue Sep 16 20:02:17 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:21 <openstack> The meeting name has been set to 'tc'
20:02:28 <ttx> Our agenda for today:
20:02:37 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:39 <mordred> o/
20:02:48 <ttx> #topic Graduation review: Zaqar (final decision)
20:03:00 <ttx> OK, so this is the last meeting before the Kilo PTL election period, so we need to come to a final decision on this
20:03:01 <sdague> o/
20:03:08 <ttx> I think it will come down to a vote on the review
20:03:13 <ttx> #link https://review.openstack.org/118592
20:03:27 <ttx> At this point I think the thread concluded that if Zaqar v2 API gets rid of some primitives, it could theoretically be backed by a queue, which would make a lot of concerns go away
20:03:31 <vishy> o/
20:03:49 <ttx> as far as I'm concerned, kilo graduation hinges on the "no major API rewrite planned" requirement:
20:04:00 <ttx> On one hand there is a new API coming up, and some see it as a requirement before joining the integrated release, so Zaqar should not graduate yet
20:04:12 <ttx> On the other hand that new API may be simple enough to implement that we are 100% sure it will make it early in Kilo, and therefore Zaqar could graduate
20:04:20 <ttx> but that's only me
20:04:35 <ttx> I'd like to hear about others
20:04:50 <zaneb> ttx: what is the timeframe for graduating a project in Kilo?
20:05:04 <markmcclain1> o/
20:05:05 <zaneb> i.e. could this be reviewed again before the summit and still make it?
20:05:07 <ttx> zaneb: we decide now that it will be shipped in the Kilo integrated release
20:05:11 <dhellmann> it sounded to me like backing zaqar by a queue would lose some of the durability features they're trying to provide. is that correct?
20:05:15 <ttx> zaneb: in theory not
20:05:17 <flaper87> FWIW, API v2 can or cannot happen depending on how strong is the requirement of getting rid of that endpoint
20:05:37 <flaper87> as a way to show how small the change is, I did this: https://review.openstack.org/#/c/121141/
20:05:41 <markmc> IMO there are probably a bunch of "devils in the details" with this v2 plan, and I'd like it not to be rushed
20:05:50 <flaper87> markmc: +1
20:05:57 <devananda> the thread on the mailing list highlights how little concensus or shared understanding of the mission, scope, and suitable use cases we all have for the project
20:05:58 <flaper87> that's what I'd prefer too
20:06:01 <markmc> I'm also not sure we should be delighted about Zaqar quickly dropping v1 and hurting existing users
20:06:02 <ttx> markmc: I tend to agree with that
20:06:05 <devananda> which seems to hinge on whether it's a queue or a message system
20:06:24 <devananda> that confusion concerns me, this close to graduation
20:06:28 <russellb> and there's a difference between "no, we've changed our mind" and "no for now, but it looks likely after 1 more cycle"
20:06:34 <mordred> russellb: ++
20:06:39 <mordred> I think we did that to ironic last cycle
20:06:43 <devananda> (and I admit to being one of the ones both caught up in, and possibly inadvertantly helping foster, that confusion)
20:06:58 <mordred> devananda: so you're saying you're involved in ALL of the confusion in openstack then
20:07:04 <russellb> ha
20:07:07 <ttx> I think we are converging. Slower than we shouldn but still
20:07:12 <devananda> mordred: totally
20:07:14 <mordred> maybe we should de-integrate devananda
20:07:20 <sdague> mordred: heh
20:07:56 <jeblair> it seems clear to me that we all want zaqar to succeed, and that is one of the most constructive openstack threads i've seen in a while.  i'm inclined to say we're not ready for each other yet but that we should continue working on it.
20:08:14 <ttx> I'm fine with keeping in incubation one cycle, but I think we need to state a clear plan and objective. I don't want to be at the same point in 6 months time
20:08:26 <mordred> jeblair: ++ ttx: ++
20:08:34 <ttx> where it's not where we want it to be ut we did not followup during the cycle
20:08:37 <russellb> yep, i don't think we did a good job on clarifying expectations on this
20:08:51 <markmc> a clear plan and objective is also important to keep this community engaged with us
20:08:58 <markmc> if we really want it to succeed
20:09:02 <mordred> also, one more cycle gives me time to write an IMAP backend plugin
20:09:18 <ttx> mordred: :)
20:09:28 <devananda> IIRC, our objections last cycle hinged on mongo and sqla back ends, which, ultimately, turned into the "is it a queue?" discussion this cycle
20:09:30 <jeblair> ttx, markmc: agreed, and i'm not sure the discussion has converged on what that is yet.
20:09:31 <devananda> markmc: ++
20:09:38 <mordred> markmc: ++
20:09:42 <flaper87> markmc: ++
20:09:43 <devananda> markmc: except I'm also not sure what that objective is now
20:10:20 <ttx> Yeah, I'm concerned that we don't have clarity on the end goal here
20:10:22 <devananda> "decide if it's a queue or a message system, and stabilize the API on that, and demonstrate that it scales appropriately"
20:10:22 <mordred> I think we need to continue the current thread until we know that
20:10:38 <mordred> step 1 - agree on step 1
20:10:42 <devananda> also, I think zaqar's team has declared it's a message system
20:10:51 <markmc> in fairness, the thread has mostly petered out
20:11:01 <devananda> https://review.openstack.org/#/c/121511/1
20:11:01 <ttx> There is almost consensus that it's not where we want it to be, and also almost consensus that we want a simple queue system somewhere in openstack
20:11:03 <markmc> not a whole lot of energy left in the participants AFAICT
20:11:11 <ttx> but that's about it
20:11:15 <devananda> by proposing a change to s/queue/message/ in the governance repo
20:11:26 <devananda> I think we can start by approving that
20:11:43 <mordred> devananda: ++
20:11:45 <jeblair> ttx: i sense that too.  i think clint said that clarification would help him work on a true queuing system
20:11:45 <zaneb> I was under the impression that removing the random access to messages pretty much resolved everyone's concerns
20:11:48 <NobodyCam> devananda: +
20:11:59 <devananda> zaneb: here's the oddity -- removing random access makes it NOT a messagign system
20:12:05 <jeblair> i mean, SpamapS :)
20:12:24 <mordred> right. this is why I think we're REALLY close to an understanding, but still aren't there
20:12:25 <zaneb> devananda: I actually don't care what you call it ;)
20:12:29 <mordred> zaneb: me either
20:12:41 <ttx> devananda: yeah...
20:12:46 <devananda> there is still this discordance -- random access => messages. no access by ID => queue.
20:12:51 <devananda> so :(
20:12:54 <mordred> but there is a thing that it is and wants to be, and since the words queue and messaging don't seem to be doing the trick, we may need to be more verbosey
20:13:03 <devananda> mordred: ++
20:13:11 <markmc> it's messages either way, just different access patterns
20:13:14 <mordred> because it's entirely possible we all think the same thing, btu we have no idea
20:13:21 <dhellmann> markmc: +1
20:13:21 <mordred> markmc: not true
20:13:22 <ttx> I feel like there are two directions... one being to embrace being a messaging system, and the other being use v2 to make a real queueing system
20:13:31 <flaper87> indeed, messaging, as stated in the thread, is a more generic term
20:13:31 <markmc> and some people seem convinced that !random access will allow the API to be backed by e.g. AMQP
20:13:32 <zaneb> so it has both queues and pub-sub, but in v2 there'd be no random access by ID
20:13:34 <devananda> markmc: I disagree
20:13:34 <ttx> personally I tend to prefer the latter
20:13:48 <flaper87> but it may also include queuing semantics
20:13:57 <flaper87> depending on what messaging pattern is chosen to consume messages
20:14:16 <devananda> flaper87: so a messaging system which can optionally be used like a queue
20:14:18 <flaper87> I'm really not sure if we should start the messaging/queuing discussion in this meeting again, really.
20:14:28 <flaper87> that said, I'm happy to move it forward in the mailing list
20:14:33 <mordred> we need one more pass on that discussion - but let's focus just on that and not on fitness for purpose
20:14:46 <mordred> and focus on getting all on the same page in terms of understanding of what we're all saying
20:15:08 <ttx> do we agree that (1) we need to define the direction and (2) we are not there yet ?
20:15:08 <flaper87> I'd like - and need - a good plan forward and requirements from this meeting (or a future one).
20:15:13 <NobodyCam> mordred: +1 and focus on getting all on the same page
20:15:24 <flaper87> Regardless on whether zaqar graduates or not, that plan is needed
20:15:33 <mordred> flaper87: ++
20:15:35 <devananda> flaper87: ++
20:15:41 <markmcclain1> flaper87: +1
20:15:46 <ttx> flaper87: if we do agree on that, we can work on the plan without the graduation time contrsint
20:15:51 <flaper87> Because there have been some concerns based on some confusions but those concerns have also confused people
20:15:58 <flaper87> at least myself :P
20:15:59 <devananda> lol
20:16:01 * jeblair is confused
20:16:30 <ttx> so do we agree that (1) we still need to define the direction and (2) we are not there yet, so integration is a bit too early  ?
20:16:37 <mordred> flaper87: also, I'm really not kidding about wanting to write a backend plugin for you - I just haven't had time to yet (thinks writing some code may clear up for him what the thing is)
20:16:45 <mordred> ttx: ++
20:16:53 <ttx> if yes, we can continue that discussion in a future meeting
20:16:57 <markmc> ttx, we == the TC, or Zaqar team, or both?
20:16:58 <flaper87> it's more than obvious that I'd prefer zaqar to graduate since we've gotten to this point but I'm happy to take more time if that's what we all need to shape it better
20:16:59 <ttx> and keep in incubation
20:17:04 <ttx> markmc: the TC
20:17:08 <markmc> ttx, cool
20:17:10 <flaper87> mordred: looking forward to that :P
20:17:28 <ttx> markmc: well, depends on which we actually
20:17:38 <markmcclain> ttx : +1
20:17:41 <markmc> ttx, first one
20:17:51 <devananda> I think https://review.openstack.org/#/c/121511/1 is the zaqar team declaring that direction
20:18:02 <ttx> markmc: do we (the TC) agree that (1) the TC and zaqar still need to define the direction and (2) zaqar is not there yet
20:18:02 <markmc> I think it's on us to define the direction we'd like to see at this point
20:18:08 <devananda> flaper87: is that correct?
20:18:20 <russellb> markmc: yep i think that's fair
20:18:31 <flaper87> devananda: yup
20:18:51 <flaper87> markmc: +1 too
20:18:52 <ttx> I really want us to have a plan that lets them achieve objectives withing the next cycle
20:18:59 <ttx> that probably means a plan pre-summit
20:19:00 <markmc> flaper87, the direction is to keep the random-access API, then?
20:19:01 <flaper87> that's part of the plan I'd like to get out of this :)
20:19:08 <ttx> so the details can be hashed out there
20:20:05 <flaper87> markmc: the direction would be to stick with the current API for now unless there are major requirements that need a new version
20:20:12 <ttx> OK, so it feels like we should defer graduation, as far as this meeting is concerned
20:20:14 <annegentle> I definitely appreciate the tenacity of the team and their patience. I think it's fair to ask for clarity while recognizing how much work they've done.
20:20:28 <ttx> and plan that discussion for the next meeting (or the one after that)
20:20:36 <annegentle> maybe by "ask for clarity" I mean "finalize API"
20:20:37 <devananda> ttx: yea, so at this point I agree that we (the TC) and the zaqar team don't have a shared grasp on what the direction is
20:20:39 <markmc> flaper87, so, the direction as you see it is to not make major changes in Kilo?
20:20:50 <markmc> if so, what are we waiting another cycle for ... ?
20:20:55 <russellb> yeah..
20:20:59 * markmc paraphrasing devananda's confusion here
20:21:01 <markmc> (right?)
20:21:15 <annegentle> and we've asked other teams to stabilize APIs in a release cycle right?
20:21:30 <dhellmann> I thought we were going to recommend potential changes, and then those would be taken into account during the summit and kilo
20:21:38 <flaper87> markmc: that's my point. We've made v1.1 as stable as possible to get to this graduation meeting
20:21:43 <zaneb> dhellmann: ++
20:21:57 <ttx> annegentle: yes, we need the API baked before we can graduate, really, otherwise it's just too much work during the first integrated cycle
20:22:03 <dhellmann> ttx: it sounds like someone needs to own making that recommendation list - not it
20:22:03 <flaper87> if there are not major changes required to graduate then I don't think waiting makes much sense
20:22:07 <markmc> devananda, then why is https://review.openstack.org/#/c/121511/1 the direction we endorse?
20:22:11 <devananda> markmc: I think the confusion right _now_ is that the TC is asking zaqar for their direction, and zaqar is asking the TC what direction to take
20:22:18 <markmc> devananda, if it's a "stay the current course" direction?
20:22:45 <markmc> (oh, sorry - that was dhellmann speaking, not devananda)
20:22:46 <markmc> heh
20:22:54 * devananda stops asking questions for a few minutes
20:23:18 <dhellmann> confusion reigns
20:23:24 <dhellmann> markmc: which bit were you directing at me?
20:23:34 <markmc> nevermind
20:23:39 <flaper87> zaqar's preferred direction is to stay as-is and keep the current API which has proven to be stable and fast for its use-case
20:23:54 <vkmc> IMO current Zaqar version is stable and there are many uses cases (https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases) that would be beneficiated from Zaqar
20:23:56 <ttx> I think we need a specific meeting to set a direction we would all be comfortable with
20:24:24 <flaper87> if the TC is not comfortable with this direction, then lets keep talking about it and work on a plan forward
20:24:24 <dhellmann> flaper87: ok, so it sounds like we need the differences between those use cases and the desired direction (if any) to be identified
20:24:49 <flaper87> as of now, those use cases are covered by the current API
20:25:01 <flaper87> I'm happy to work on a more detailed explanation for those use cases
20:25:09 <flaper87> but I'll need support for other teams too
20:25:19 <flaper87> since I gathered them based on other projects needs
20:25:23 <flaper87> s/I/we/
20:25:24 <markmc> right, this supposed/potential TC "desired direction" is to remove support for some use cases
20:25:39 <flaper87> markmc: which is what scares me a bit
20:25:41 <dhellmann> I guess we need someone who thinks there is a gap to step in and write up the difference then
20:25:49 <markmc> and just that, or also re-architect to optimize just for those use cases?
20:25:59 <flaper87> I'd like zaqar to be able to support those use cases since I think they are fair and important for cloud services
20:26:07 <dhellmann> yeah, I'm not sure I agree with removing the use cases just to fit our notion of some other thing that zaqar might not be trying to emulate
20:26:09 <ttx> OK, so I'm not sure we made a conclusion here. Is it "we don't want to graduate it the way it stands" ? Should we still vote on graduation on the current featureset and API ?
20:26:27 <ttx> we seem to have two options:
20:26:32 <annegentle> some of this plan sounds like conscription :) I kid I kid
20:26:34 <ttx> 1- graduate it the way it is now
20:26:43 <russellb> if it's "we don't want to graduate", i'm missing the clear justification now i think
20:26:50 <ttx> 2- keep it in incubation and clearly state what we'd prefer
20:26:52 <dhellmann> russellb: +1
20:27:17 <markmc> I'm still open to (2), but right now leaning to (1)
20:27:18 <ttx> I'm fine with picking(2) now and elaborating on that in a future meeting
20:27:33 * flaper87 is fine with (1)
20:27:37 <flaper87> (joke) :P
20:27:44 <flaper87> I mean, not a joke but...
20:27:46 <flaper87> :D
20:27:47 <ttx> so it looks like we still need to vote.
20:27:53 <dhellmann> I would only want to go with 2 if we had a commitment from someone here now to do the work of writing up clearly what we'd prefer, and then we all come back and agree on that
20:27:55 <ttx> +1 would support (1)
20:28:01 <ttx> -1 would support (2)
20:28:05 <ttx> is that fair ?
20:28:12 <devananda> ttx: does voting now in any way affect the ability of zaqar to remain in incubation one more cycle (eg, if the vote does not pass)
20:28:33 <flaper87> ttx: sounds fair to me
20:28:35 <russellb> i *think* there's consensus that a -1 is just "1 more cycle"
20:28:35 <dhellmann> we're just taking the temperature of the room, right? we vote officially via gerrit?
20:28:47 <russellb> that's my feeling anyway
20:28:47 <ttx> not, -1 would be a vote for (2) (keep it in incubation and clearly state what we'd prefer)
20:29:00 <dhellmann> well, why not vote 1 and 2 then :-)
20:29:13 <ttx> dhellmann: no I felt like we should vote on the review
20:29:23 <ttx> we need a final decision on this today
20:29:24 <dhellmann> ah, I thought you meant here in the meeting
20:29:39 <ttx> well, can be on the review during the meeting
20:29:58 <ttx> https://review.openstack.org/118592
20:30:13 <mikal> So we're voting on the review now then?
20:30:24 <flaper87> the sooner you guys vote, the sooner I'll get all this tension out of me :P
20:30:25 <ttx> mikal: that's my proposal, yes, unless someone objects
20:30:40 <vkmc> sounds good to me
20:30:47 * jroll watches gerrit crash from flaper87 and friends f5'ing that review :P
20:30:48 * devananda votes on the dependent change (s/queue/messaging/)
20:30:48 <clarkb> a
20:31:01 <flaper87> jroll: pretty much
20:32:11 <ttx> russellb, markmc, annegentle, mikal, mordred, devananda, vishy, markmcclain, jeblair, jaypipes, sdague, dhellmann : ok with voting now on https://review.openstack.org/118592 between "graduate now" and "incubate a bit more, with plan coming up in subsequent meeting" ?
20:32:20 <russellb> yes
20:32:22 <sdague> ttx: yep, done
20:32:24 <flaper87> ttx: they're voting :P
20:32:27 * flaper87 is refreshing
20:32:27 <devananda> yes
20:32:31 * ttx F5s
20:32:33 <dhellmann> yeah
20:33:19 <ttx> we might not have a final decision today, as some members are not around to vote
20:33:23 <ttx> but i'll chase them down tomorrow
20:33:56 <flaper87> ttx: kk, thanks
20:34:02 <ttx> in the mean time let's switch to next topic
20:34:07 <ttx> #topic Graduation review: Ironic (final decision)
20:34:10 <flaper87> thank you all!
20:34:15 <ttx> #link https://review.openstack.org/120225
20:34:17 <vkmc> thanks!
20:34:37 <ttx> flaper87: don't thank us -- I think we failed to provide the guidance you needed, if anything
20:34:55 <ttx> on Ironic: I think the concerns that were raised as last-minute objections last week were covered
20:35:01 <mikal> I agree we haven't covered ourselves with glory
20:35:09 <ttx> And no TC member raised new objections on the thread at:
20:35:13 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2014-September/000808.html
20:35:17 <mikal> I'm ready to vote on ironic for what its worth
20:35:23 <ttx> so unless we have a last-minute surprise, this looks good to go
20:35:30 <devananda> I will abstain on voting on Ironic for obvious reasons
20:37:20 <sdague> for posterity, it will be interesting if people upgrading come out of the woodwork later. Not really important in the grand scheme of things, but it's amazing how many new bugs for nova are getting filed on grizzly clouds.
20:37:23 * jeblair wonders if our quorum is still a quorum
20:37:39 <sdague> well there are 6 ironic votes so far
20:37:41 <devananda> sdague: it will be interesting indeed
20:37:55 <markmc> jeblair, always hard to judge that :)
20:38:02 * mordred is here
20:38:40 <JayF> For clarity; what's the bar for graduation? Majority? Plurality? 2/3? Unanimous?
20:38:42 <jeblair> and 7 yay
20:38:52 <ttx> actually not
20:39:20 <ttx> It's more yes than No and at least 5 yes votes
20:39:32 <ttx> 7 just cuts the vote short
20:39:42 <JayF> Thanks, ttx.
20:39:48 <ttx> http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n88
20:39:59 * devananda waits for the meeting to resume
20:40:04 <markmcclain> well 9 carries
20:40:12 <ttx> and 10 even more
20:40:19 <ttx> ok, that's a win
20:40:40 * ttx approves it
20:40:45 <devananda> thanks, everyone
20:40:54 <NobodyCam> thank you TC!
20:40:58 <lucasagomes> thanks!!
20:41:03 <devananda> the feedback in atlanta and at the midcycle was incredibly helpful in getting here
20:41:15 <jroll> \o/ thanks all :)
20:41:16 <devananda> I know a lot of you put in a lot of effort to helping us achieve this :)
20:41:19 <ttx> devananda: looks like it takes us 3 cycles to give good feedback
20:41:40 <devananda> ttx: yep. and two cycles before that to prove out the idea (when it was in Nova)
20:41:57 <devananda> really, that's not so long in the scheme of things
20:43:19 <sdague> devananda: so do you have the baremetal deprecation patches up for nova?
20:43:33 <sdague> I for one look forward to gutting that in the future
20:43:48 <devananda> sdague: nope. I think mikal and dansmith were going to fight over who was going to push that button, and I wanted to watch
20:43:55 <mikal> Well, let's not land those until Kilo
20:44:00 <devananda> mikal: ++
20:44:02 <mikal> Heh
20:44:06 <markmcclain> haha
20:44:07 <russellb> not mark deprecated in juno release?
20:44:09 <sdague> mikal: we can land deprecation... right?
20:44:14 <russellb> and then remove in kilo
20:44:16 <devananda> it's already marked deprecated, isn't it?
20:44:20 <mikal> sdague: oh true
20:44:22 <sdague> I thought our intent was deprecate now
20:44:26 <russellb> devananda: doubt it
20:44:29 <mikal> sdague: I was thinking code delete
20:44:30 <sdague> devananda: not as far as I know
20:44:39 <devananda> also, the proxy API landed, so we ought to turn that on by default (I'm not sure if it is or not)
20:44:58 <sdague> devananda: so a TODO for you to make sure we've got bm deprecated :)
20:45:01 <ttx> #topic Extra ATC patches
20:45:09 <ttx> We have a number of those currently proposed.
20:45:15 <ttx> * Add Juno Compute co-authored-by authors to extra-atcs (https://review.openstack.org/119666)
20:45:18 <ttx> * Adds Telemetry Juno co-authors as ATCs (https://review.openstack.org/119794)
20:45:23 <ttx> * Adds Documentation co-authors as ATCs. (https://review.openstack.org/119757)
20:45:26 <sdague> ttx: I assume these are procedural and you should just +A them through
20:45:29 <devananda> sdague: http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/baremetal/driver.py#n128
20:45:34 <ttx> well, maybe not. As anteaya mentioned on 119666, since this piggy-backs on the extra-atcs process, it makes sense that the extra ATCs are proposed by a sponsor who checks that the names proposed are reasonable
20:45:40 <mikal> sdague: they wre more contentious than I expected
20:45:44 <devananda> ttx: there was a question whether all those extra atc's have signed the CLA or not
20:45:47 <devananda> ttx: was taht answered?
20:46:00 <sdague> devananda: it doesn't matter, their code is already in
20:46:01 <ttx> CLa is not an issue
20:46:06 <devananda> k
20:46:10 <dhellmann> mikal: I noticed a couple of folks on the nova one that seemed to also have nova commits (unless I misunderstood the comments). I'm not sure that matters, but I did want to point it out.
20:46:14 <ttx> we need to make due diligence checking they are foundation members
20:46:16 <annegentle> sdague: that's my sense of it, it's the mechanical process we have for now, but even so that process requires TC review
20:46:22 <mikal> dhellmann: that's a timing thing
20:46:24 <ttx> So I think PTLs should propose for their projects, rather than one review for all (they know the names they propose and vouch for them)
20:46:28 <dhellmann> mikal: ?
20:46:37 <ttx> Then we need to doublecheck that the proposed names are Foundation members, since ATCs must be foundation members according to the Foundation bylaws.
20:46:38 <mikal> dhellmann: the primary author line is commits ever, the addition is based on commits post 1 April 2014
20:46:41 <sdague> dhellmann: so if this is for ATC conference, it probably doesn't matter
20:46:44 <dhellmann> mikal: ah, ok
20:46:45 <ttx> We have until next week to get that straight, so I'll probably be in touch.
20:46:55 <mikal> dhellmann: so, if you didn't do any primary commits since 1 April, but did in the past, you end up like that
20:46:57 <devananda> ttx: I think that's reasonable, but it would be really helpful to have an automated way to do that check (maybe we already do?)
20:47:04 <dhellmann> mikal: ok, changed to +1 then
20:47:13 <mordred> ttx: I proposed a new thought to bryce last night
20:47:15 <dhellmann> sdague: I was worried about duplicate ballots if the names didn't match exactly
20:47:15 <ttx> devananda: we ahve a script from Doug to help
20:47:16 <anteaya> devananda: we don't
20:47:23 <mordred> ttx: that it is not possible to be an ATC and not a foundation member
20:47:24 <ttx> mordred: I think it works
20:47:27 <annegentle> agreed on the PTLs proposing
20:47:29 <anteaya> devananda: the fact we don't is a huge pain point
20:47:38 <devananda> anteaya: :(
20:47:42 <anteaya> yes
20:47:43 <dhellmann> devananda: https://review.openstack.org/121696
20:47:45 <anteaya> I am very sad
20:47:46 <mordred> ttx: so I'm currently arguing that we do not need an additional check
20:47:59 <ttx> mordred: even for extra-atcs ?
20:48:10 <ttx> mordred: who do not have a gerrit account?
20:48:10 <anteaya> dhellmann: the fungi script removes dups
20:48:16 <mordred> yah. there is no barrier to entry for foundation membership except for interest
20:48:20 <anteaya> dhellmann: and so does the polling app
20:48:21 <mordred> I'd say a patch indicates interest
20:48:23 <dhellmann> anteaya: I should have known he'd have that covered.
20:48:27 <jeblair> mordred: i thought there was an agreement
20:48:32 <anteaya> dhellmann: good to ask though
20:48:37 <mordred> jeblair: oh - maybe so
20:48:53 <jeblair> https://www.openstack.org/join/register/
20:49:09 <jeblair> not that i'm excited about that or anything
20:49:13 <ttx> mordred: i'm fine with that -- we are spending way too much time on this, while foundation membership is essentially not proving anything
20:49:31 * markmc is confused what the debate is here
20:49:36 <jeblair> ttx, mordred: ++
20:49:37 <fungi> right, however we do have one extra atc dupe currently which is not automatically removed because she's contributed code with different e-mail addresses than the one for her in the extra-atcs file, but that's tractable
20:49:39 <anteaya> I just need to ensure the elections are compliant with the charter
20:49:44 <markmc> PTLs can nominate extra PTLs, and that's what they've done? Right?
20:49:55 <anteaya> fungi: thanks for picking that up
20:49:57 <mordred> jeblair: I think my point was actually that if yuo were _ever_ a foundation member, which you should be with our current system in order to be a contributor, then it's pretty impossible for an active dev to lose it
20:49:58 <markmc> anyone think any of the proposed people don't deserve ATC status?
20:49:59 <ttx> markmc: yes, but ATC requires in theory that you are a foundation member
20:50:15 <ttx> markmc: so we may have to check that
20:50:16 <markmc> ttx, do we think any of them aren't foundation members?
20:50:22 <ttx> markmc: we do.
20:50:27 <markmc> ttx, which ones?
20:50:28 <annegentle> I want more ptls, how does this cloning occur?
20:50:29 <jeblair> mordred: ah, yes, contributing a patch is sustaining interest.  makes sense
20:50:33 <mikal> markmc: for my patch, I checked foundation status and they're all ok
20:50:39 <markmc> mikal, right, I saw ...
20:50:45 <mikal> markmc: just checking...
20:50:45 <zaneb> annegentle: lol
20:50:46 <anteaya> mikal: you did a marvelous job
20:50:52 <mordred> jeblair: so as long as the person _has_ an account in gerrit, they're an ATC and a foundation member
20:50:53 <ttx> markmc: jaromir Coufal for example
20:50:54 <mikal> Its true I am fantastic
20:50:58 <mikal> (Sarcasm)
20:51:09 <sdague> so I think honestly just ask each PTL if they checked foundation membership status
20:51:12 <markmc> ttx, he was already approved though :)
20:51:17 <sdague> if they say yes, it's procedural
20:51:18 <ttx> markmc: my point :)
20:51:22 <markmc> sdague, right, make it part of the process
20:51:22 <dhellmann> mikal: no, really, take a minute to brag about your work :-)
20:51:23 <jeblair> mordred: er, you can have an account in gerrit and never have joined the foundation
20:51:52 <mordred> jeblair: yah - sorry, account in gerrit and cla flag signed
20:52:13 <mikal> mordred: and you need both of those for gerrit to allow a code upload, yes?
20:52:25 <mordred> mikal: yes - but we do not enforce it for co-authored-by
20:52:35 <mikal> mordred: yep, I get that
20:52:46 <ttx> so it looks like the Zaqar vote hinges on dhellmann and jaypipes
20:52:54 <anteaya> mikal: just the inital code upload
20:52:57 <mikal> mordred: there's an explaination of how I tried to work it out in the commit message for 119666
20:53:00 <sdague> honestly, I feel like the edge cases aren't super interesting here. If someone wants to object later to someone else's ATC membership, so be it. But I think we should operate on good faith from the PTL
20:53:07 <mordred> sdague: ++
20:53:16 <anteaya> the edge cases are important to me
20:53:18 <ttx> yeah, i'm ready to take a leap of faith at this point
20:53:42 <anteaya> since these are the folks the 1% that I have to spend time verifying if their ballot is lost
20:53:56 <ttx> mordred: to close the loophole I wanted to research those names and propose that they join the foundation though
20:54:01 <anteaya> which I figure will be around 20 people this round
20:54:19 <sdague> anteaya: but that's the false negative case right?
20:54:21 <dhellmann> sdague: yeah, I think we're just trying to make anteaya and fungi's jobs easier come election time
20:54:25 <anteaya> sdague: some are
20:54:27 <ttx> which is what I meant by "due diligence"
20:54:34 <anteaya> dhellmann: yes and thank you
20:54:41 <fungi> anteaya: how many ask you why they received a ballot and claim to not be contributors?
20:54:49 <anteaya> fungi: none
20:55:05 <anteaya> is that what sdague meant by false negative?
20:55:09 <sdague> anteaya: right, but that seems to be the way we might possible error
20:55:09 <fungi> which is the theoretical risk being presented here
20:55:10 <anteaya> sorry I miss understood
20:55:16 <anteaya> sdague: one way
20:55:22 <sdague> and, honestly, I'm ok with that error
20:55:39 <anteaya> if the rest of the tc is too, then fine
20:55:46 <anteaya> since I take my direction from the tc
20:56:50 <fungi> it doesn't seem likely to either increase or complicate the case of people who expected ballots not receiving them
20:57:37 <anteaya> fwiw this is coming about since the offering of the resign button
20:57:57 <anteaya> this sort of issue was never an issue prior to the availability of that feature
20:58:14 <anteaya> did everybody leave?
20:58:27 <dhellmann> we do want the rolls to be reduced, though, to make passing changes easier
20:58:37 <sdague> no idea, I just figured I'd stated my point and was waiting for others to say a thing :)
20:58:38 <annegentle> anteaya: in my case it was a big book sprint
20:58:51 <anteaya> annegentle: and you confirmed all your names, thank you
20:58:52 <ttx> OK, we can resolve that one off-meeting
20:58:56 <annegentle> anteaya: with newcomers with cloud architectures in their heads that wanted out
20:58:59 <ttx> and on the patches
20:59:04 <ttx> we need to cover a bit more
20:59:08 <ttx> #topic Project Testing interface description update
20:59:12 <ttx> mordred has been pushing a number of patches about the project testing interface:
20:59:15 <ttx> * Import the Project Testing Interface description (https://review.openstack.org/119872)
20:59:18 <ttx> * Two minor style cleanups (https://review.openstack.org/119873)
20:59:22 <ttx> * Update testing interface to reflect reality (https://review.openstack.org/119874)
20:59:25 <ttx> * Add a docs environment to the testing interface (https://review.openstack.org/119875)
20:59:29 <ttx> I think they all reflect the current situation, and will approve them whenever they get 7 +1s
20:59:37 <ttx> #topic Other governance changes
20:59:43 <ttx> * The Oslo program is adopting pylockfile (https://review.openstack.org/117622)
20:59:44 <mordred> ttx: one is different
20:59:46 <dhellmann> I would really like to have https://review.openstack.org/#/c/117622/ resolved, too, since we're already acting like oslo has adopted the library and if I need to undo that or move it to stackforge or something I'd like to do it soon
20:59:52 <mordred> ttx: ONE may need to be discussed, it's a new idea
20:59:53 <dhellmann> heh, timing
20:59:54 <ttx> mikal and russellb still have -1s on this one
21:00:02 <ttx> mordred: which one?
21:00:08 <markmc> dhellmann, that was one awesome justification logic sequence thing! :)
21:00:08 <mordred> ttx: docs venv
21:00:11 <ttx> dhellmann posted the rationale for it, so let us know if your concerns still stand
21:00:17 * dhellmann takes a bow
21:00:20 * mikal looks
21:00:20 <markmc> "here's our reasoning" heh
21:00:20 <mordred> ttx: I mean, it's also the current de facto, so you can probably just +A it
21:00:25 <mordred> but it _is_ mildly new
21:00:36 <russellb> i wonder why i have a -1
21:00:39 <ttx> mordred: yes, would like to get 7 yes on that one
21:00:43 <russellb> i wonder if it was just gertty n00b fail
21:00:48 <mordred> ttx: kk
21:00:48 <jeblair> mordred: it's not defacto
21:00:52 <jeblair> it's actually a substantial change
21:01:04 <mordred> jeblair: there are only 13 repos in all of our repos that do not have it
21:01:04 <ttx> * Add keystoneclient-kerberos repo to Keystone (https://review.openstack.org/120310)
21:01:09 <ttx> This is a classic project addition. We'll need dolphm's ack on this one, then unless someone objects it will be approved
21:01:11 <russellb> changed to +1
21:01:13 <ttx> * Add tempest-lib to the QA Program (https://review.openstack.org/119935)
21:01:13 <jeblair> the question is about whether we support running anything before docs
21:01:19 <ttx> Same here, but the PTL proposed it so I assume he is OK with it. Will approve tomorrow, unless someone complains
21:01:20 <jeblair> okay we're not talking about it. nevermind.
21:01:24 <ttx> * Add reference to neutronincubator project (https://review.openstack.org/117000)
21:01:29 <ttx> markmcclain: Should this one be abandoned now ?
21:01:47 <mordred> jeblair: nod. let's get ttx to put it on next weeks' meeting
21:01:53 <markmcclain> ttx: likely but one last item to finalize before I remove it
21:02:30 <ttx> markmcclain: ok
21:02:31 <ttx> #topic Open discussion
21:02:34 <ttx> As a reminder, we'll have a phone presentation on CLA/DCO by Mark Radcliffe
21:02:37 <ttx> Thursday at 15:00 UTC for those interested
21:02:54 <ttx> So it looks like the zaqar vote reached 7 no
21:03:17 <jeblair> i proposed this change on the cla/dco https://review.openstack.org/#/c/120260/
21:03:28 <jeblair> i don't think the board has that on the agenda this thursday, so i don't think it's urgent
21:03:35 <ttx> I'll wait for jaypipes to vote and check if anyone changes their vote in the mean time, then officialize the result
21:03:38 <annegentle> jeblair: re: without docs do you mean kerberos/keystone info?
21:03:43 <ttx> and we are out of time
21:04:06 <jeblair> annegentle: sorry?  what's the context?
21:04:11 <ttx> jeblair: I wanted us to discuss it next week, once we get Radcliffe's perspective
21:04:25 <annegentle> [16:01] <jeblair> okay we're not talking about it. nevermind.
21:04:29 <ttx> #endmeeting