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