20:01:01 #startmeeting tc 20:01:02 Meeting started Tue May 16 20:01:01 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:06 The meeting name has been set to 'tc' 20:01:10 Was great seeing you all last week in person! 20:01:13 o/ 20:01:18 Our agenda for today is at: 20:01:22 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:23 * edleafe wanders aimlessly 20:01:34 Reminder that you can all use #info #idea and #link to help build a more readable summary 20:01:44 #topic Boston feedback and immediate action items 20:01:50 Wanted to spend a few minutes to get for feedback on the Forum 20:01:56 err -for 20:02:06 and also to write down a few #action points for the TC from the discussions that happened there 20:02:09 o/ 20:02:28 in case we missed anything we need to track 20:02:33 (beyond the ones that are already on the agenda for this meeting) 20:02:38 ttx: I have one... 20:02:46 notmyname: sure shoot 20:03:18 a community member expressed some frustration that our team's sessions were restricted, yet there were plenty of empty rooms, especially on wed-thurs 20:04:02 notmyname: two things on that 20:04:14 I would agree that Thursday afternoon was under-utilized 20:04:28 Original plan was to keep it for continuing discussion 20:04:33 and last-minute topics 20:04:44 but in the end almost nobody scheduled anything there 20:04:47 (sign up for Thu afternoon was here - https://wiki.openstack.org/wiki/Forum/Boston2017) 20:05:03 o/ 20:05:06 Hacking rooms were available but rarely used. 20:05:10 There were also hacking rooms available to drop int. 20:05:13 smcginnis, lol 20:05:17 i have feedback unrelated to ^ 20:05:20 diablo_rojo: ;) 20:05:23 As far as empty rooms on Wed and Thu morning, not sure.... we limited the number of concurrent sessions to 3. Are you suggesting we hhould have had more ? 20:05:26 should* 20:05:26 * rockyg wanders in and sits near edleafe 20:05:40 right. we ended up scheduling something on that wiki page (i missed that announcement). and we dropped in a hackingroom 20:05:45 * edleafe passes rocky_g some popcorn 20:05:58 I think the thurs sign up process was maybe less clear, it would have been nice to have a whiteboard in the hallway for those sessions instead of the wiki. Something that could be more organic. 20:06:02 ttx: yes, I think more concurrent sessions would have been fine 20:06:13 sdague: I like that idea. 20:06:14 sdague, ++ 20:06:21 notmyname: noted 20:06:29 ttx: just wanted to raise the point as feedback. I'll pass it along, too 20:06:36 What do you guys think ? CAn we afford more than 3 concurrent sessions ? 20:06:44 ttx: we can certainly try 20:06:51 personally I appreciated it being only 3 way 20:06:52 i wouldn't 20:06:53 also, I like sdague's idea 20:07:04 or, at least, we should communicate better the sign up process 20:07:08 the point of the forum is to get people together, in a forum, for discussion, right? 20:07:10 Even with only three there were some notable conflicts, but not as many as I recall from the past 20:07:10 I feel like I was not overextended, but then I'm not involved in day-to-day development 20:07:14 because I was only double booked twice instead of 6 or 8 times 20:07:15 too much concurrency and you miss out on things 20:07:20 sdague: yeah 20:07:24 mriedem++ 20:07:28 ++ mriedem 20:07:36 we could also have most days with 3 concurrent sessions, and one day with 4, I guess 20:07:44 yeah, planning for the overflow sessions was a little last minute. something physical on site might work better next time. 20:07:46 although from a space utilization perspective it's suboptimal 20:07:50 I agree it'd be awesome to avoid overlaps as much as possible. 20:08:02 ttx: 3x3 and 1x4 ++ 20:08:12 i'd never want to see >3 concurrent sessions 20:08:17 mriedem: ++ 20:08:22 mriedem, ++ 20:08:23 hell i'd be happy if there were 2 20:08:24 even without personal conflicts, getting a critical mass of "the right people" into a room is easier with fewer sessions 20:08:25 notmyname: do you feel like you missed on user feedback due to less sessions being available ? 20:08:31 (comapred to previous summits) 20:08:38 i didn't get user feedback 20:08:40 was my complaint 20:08:42 the point of this was to get us more mixing together, not replicating the 20+ track PTG everyone in a corner 20:08:43 or operator really, 20:08:53 sdague: indeed 20:08:55 Just have bookable (on site, like sdague said) rooms so adhoc sessions can happen around emerging topis 20:08:58 in general i didn't feel the forum was any different from the first 2 days of design summit in previous summits 20:09:06 i liked that pretty much all of the forum sessions were non-project-specific but were instead topic-specific 20:09:16 fungi: ++ 20:09:20 fungi : ++ that's what we wanted 20:09:22 fungi++ 20:09:22 agree fungi 20:09:25 mriedem: pretty much 20:09:26 i still got the feeling most things were dev-driven, 20:09:28 and dev-centric 20:09:32 like, 20:09:39 ttx: definitely. previous summits had much better feedback and progress made. although we made use of the hacking rooms when we found them, we even had someone (an operator and new to the community--first in-person event) didn't have any idea where any of the rest of the community was 20:09:40 devs: "here is the plan, what do you think?" 20:09:44 mriedem: in my sessions I saw a lot more ops involved than we used to, but maybe those were the less dev-oriented 20:09:44 everyone else: "crickets" 20:10:06 regarding project onboarding, some teams got good turnout, others did not 20:10:09 mriedem: that was the hardest thing to avoid but I think many of us intervined more than once suggesting to not dive into "dev" specific discussions 20:10:19 ttx: so the discoverability of sessions, especially in the hacking rooms, was bad. a whiteboard schedule would really help with that (a la sdague) 20:10:20 mriedem: any example of the sessions where that happened? 20:10:29 That was not the case for most of the sessions I attended 20:10:30 so, except for the quotas session, I feel like the operators there were the same ones that were always there. Maybe it's a transition, but it didn't seem to be substantially different in that regard 20:10:37 so it'd be interesting to know when that happened 20:10:39 sdague: same 20:10:45 flaper87: the claims in the scheduler session, 20:10:47 are we competing with presentations? 20:10:51 the instance/volume affinity HPC session 20:10:54 dhellmann: there is also that 20:10:54 dhellmann: yes 20:10:54 I don't know how to avoid that, if we are 20:11:01 there are also talks i'd like to attend 20:11:13 like people presenting on their upgrade and scaling issues 20:11:20 i feel that's where the 'user' feedback is 20:11:25 but the devs are all in a forum cave 20:11:30 I prioritized forum sessions because they are not recorded and you actively participate in them. I just watch videos later 20:11:36 mriedem, ++ 20:11:37 i was able to get to some talks and learn new stuff 20:11:45 ttx: that's what I do 20:11:48 mriedem: ++ 20:11:56 mostly prioritize on talking to people at the forum while I can 20:12:05 ttx: I do that, too. I wonder if we're still too segregated, though, if ops are prioritizing presentations over discussions 20:12:06 flaper87: i generally talk to the people i know, 20:12:11 it's the people i don't that i'm missing 20:12:11 I really wanted to attend more sessions than I did (to learn new stuff) but felt obliged to be in the forum rooms (mostly 102 for some reason) 20:12:19 the problem with watch later, is it doesn't provide a clear way to continue the conversation 20:12:27 sdague: yes, 20:12:35 and my todo list grows and i don't actually watch later :) 20:12:43 Don't hesitate to mention that in the official feedback form 20:12:46 There are ops sessions (some inforums, some in presos) that have really good info for devs. the LDT sessions talk about workarounds for scaling and other issues 20:12:46 heh, yeh, I hear you 20:12:56 cdent: mostly 102 here too :P 20:12:59 &/rdo 20:13:03 oops 20:13:23 overall, it was a great positive experience for me inspite of the daily commute :) 20:13:24 happy to receive suggestions on how to improve the format 20:13:35 anyway, in general i get the sense that unless i ask a very specific question to ops/users (where are the users anyway?), i don't get any feedback 20:13:53 I thought it was great for the first time effort 20:14:00 rockyg: +1 20:14:14 some sessions were definitely still sounding like old design summit discussions, but some others definitely had a new feel 20:14:15 also, record the onboarding rooms next time 20:14:23 mriedem: ++ 20:14:27 that's hard with audio though 20:14:32 mriedem: yes, many projects thought the same thing 20:14:34 but, mics i gues 20:14:35 We may just record our own. 20:14:36 despite it having some bumps I thought it was way better having the forum than having the old style summit 20:14:37 a number of the "presentations" were actually feedback-oriented panels too 20:14:59 fungi, ++ 20:15:08 ok, let's move on -- but feel free to express your feedback on the ML, the survey or by email to me 20:15:10 for example, in the security panel we spent about 50% of the time on prepared questions and the other 50% on audience questions 20:15:26 fungi: And one "we ran OpenStack and here are all the failures we had." :/ 20:15:47 is there a feedback thread? 20:16:00 part of the confusion, especially for users/ops this round was they thought they needed to get into the presentation schedule when they really could have done better in the forum 20:16:06 Recording on-boarding and improving late scheduling and publicizing the hacking room schedule are all no-brainer optimizations in my opinion 20:16:15 mriedem : go ahead start one :) i didn't see any 20:16:26 ttx: +1 20:16:27 adding more parallel discussions is likely a two-edged sword 20:16:44 I've also heard some feedback about some Forum sessions without much agenda. For the next Forum, I would maybe be a little bit more engaged to push people to prepare the sessions they're supposed to lead 20:17:00 EmilienM: yes, in some preperation was a bit minimal 20:17:05 I've found some Forum sessions well prepared, where the discussion happened smoothly and finished before time 20:17:23 one fish bowl did not have a moderator, but that kind of stuff happens.. 20:17:23 on the opposite, some sessions didn't have any etherpad or agenda before it started 20:17:34 dims: the one with k8s & orchestration? 20:17:52 EmilienM : y and we drafted the kolla-kubernetes folks in the room to run it 20:18:03 anyway, we should maybe push people to prepare better next time 20:18:14 I propose we move on 20:18:17 lots of Asia folks didn't get their visas 20:18:18 ttx: ++ 20:18:20 let's quickly discuss post-forum action steps for a number of already-submitted proposals 20:18:21 I wonder if there's a good way we can tag forum sessions to let operators know which ones it would be good for them to attend. 20:18:24 Other than all. 20:18:30 #topic Next steps for TC vision 20:18:32 ++ smcginnis 20:18:32 ttx: Yes, let's move on. 20:18:37 Proposed draft is here: 20:18:40 #link https://review.openstack.org/453262 20:18:48 Feedback was collected on the review, on an anonymous survey and in a summit presentation last week 20:19:29 My brain is a bit mushy but I think someone signed up to collect and organize the feedback into a number of changes 20:19:44 some cosmetic that we can probably easily include 20:19:47 ttx: I don't think anyone actually committed to the next phase 20:19:54 some deeper that might require further discussion 20:20:05 because my todo list got crowded like mriedem's, I haven't seen it yet: is the video of that session going to be coherent enough to watch now? 20:20:05 we definitely need probably two folks to tackle the next draft 20:20:08 sdague: might have been gothicmindfood or johnthetubaguy during that session 20:20:26 but then I don't want to sign them up if my memories are unclear 20:20:42 I'll follow up with them 20:20:51 having done the last draft consolidation, it would be good if it was "notme" so that other voices mix in here, and I don't accidentally skew too far 20:21:04 I'll happily volunteer to help someone else (who was at the session and has access to the feedback survey) 20:21:04 #action ttx to follow up with gothicmindfood / johnthetubaguy re: next step on TC vision 20:21:17 #info cdent volunteers to help 20:21:20 * dtroyer can also help out here 20:21:32 #info so does dtroyer 20:21:45 I still need to review the session recording. I'll try to add comments as I do that as well. 20:21:56 ok moving on, since we are missing the people who actually know what's going on 20:21:59 there weren't a ton of feedback in the session itself 20:22:06 the spread sheet is the big one 20:22:15 feedback in-session was mostly positive 20:22:25 * flaper87 is sad to have missed that session 20:22:29 especially as there are bunches of conflicting commentary in there, so it's going to require judgement 20:22:31 but yes, not much. A lot of people were hearing the vision for the first time 20:22:39 (one example of conflicting sessions for me) 20:22:51 yeh, timing it against the pike goals session was less than ideal 20:22:51 ttx: good stuff 20:22:59 flaper87: I hear one of the speakers was awesome. Just sayin 20:23:00 sdague: +1 20:23:04 ttx: :P 20:23:13 #topic Next steps for assert:supports-api-compatibility 20:23:19 #link https://review.openstack.org/418010 20:23:22 The dependency review (https://review.openstack.org/#/c/421846) was approved recently 20:23:26 cdent suggested on the review that it should be renamed to supports-api-interoperability 20:23:44 not sure how many cycles mtreinish will dedicate to a new rev 20:23:47 only because that word became the key word when resolving the dependent review 20:23:52 or if someone should pick it up 20:24:18 since it's missing a few things as dhellmann noted 20:24:18 he's out today, I can poke him when he's back later this week to see 20:24:21 I can do it if necessary. I'm a bit more concerned about the issue with the api-wg potentially being the arbiter 20:24:28 sdague: ok 20:24:40 which would be an important change in activity 20:24:50 #action sdague to follow up with mtreinish to see if he will push it to the end 20:25:02 cdent : I asked about that because it wasn't clear who would manage the tag. I don't know if it's a good idea or not. 20:25:22 me neither :) 20:25:25 #topic Next steps for deprecate postgresql in OpenStack 20:25:27 it has worked for some other teams, but maybe the WG isn't able to do it? or doesn't want to? 20:25:35 #link https://review.openstack.org/427880 20:25:39 sdague already refreshed it based on the forum discussion 20:25:45 I think we can iterate on the review 20:25:47 Based on the change proposed, it doesn't seem to me like "deprecate" is the right term now. 20:26:01 also 20:26:05 #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/116642.html 20:26:19 I would not mind if we also explained the kind of involvement we'd like to see to revert the course of action 20:26:24 for ml thread (which there is no response on yet, though there is some gerrit responses) 20:26:42 ttx: that has never been successful 20:26:54 which makes me think -- how is the ML/Gerrit discussion mix working for you all 20:27:06 feels like it doesn't realy make it easy to follow 20:27:08 yeah, my impression was we were going to close this off and *not* ask for action to reverse it 20:27:20 asking folks that don't really think there is value in doing the work, to assess and break down the work for other people into chunks they might decide to fund, just isn't a virtuous cycle 20:28:00 sdague: in other words.. If there was someone who made it work (without us asking) would we likely revert the course ? 20:28:07 ttx: yes 20:28:21 Anyone talk to the postgres folks in the marketplace? 20:28:25 ok, I can follow that. Agree asking hasn't served us that well anyway 20:28:26 if you are removing work from existing upstream folks 20:28:37 Totally unaware of Postgres in the control plane. 20:28:39 you get the freedom and trust to also do things important to you 20:28:43 suggested they get involved. 20:28:50 sdague: yes, by "involved" I mean shouldering significant QA work otherwise 20:28:54 cynical perhaps, but i see the main benefit in outlining what would be needed to reverse direction is that we can point at it to show that we provided an alternative nobody took us up on 20:28:56 They might be good candidates to recruit 20:29:17 fungi, ++ 20:29:17 ttx: by "shouldering the QA work", do you mean running CI outside of our normal gate? 20:29:20 rockyg : see the links above, and the forum session. We've been trying to get people to get involved in the discussion. 20:29:34 smcginnis: no I mean helping the QA team by funding people to work there 20:29:43 ttx: and proactively engaging in upgrade work, and reviews in projects that need an rdbms (which is many of them) 20:29:53 it's not just final QA, it's being early in the process as well 20:30:28 ttx: Seems like a narrow slice of work to have specific people called out as "funded for pg" work. 20:30:29 smcginnis: so, if I change the title to "Be clear about support level of Postgresql", you would be happier 20:30:32 sdague : some downstream teams seem to start looking at stuff only after we push out a release so by then it's too late 20:30:33 dhellmann, these guys were clueless. Users, but no idea how to participate. but interested when they heard about it. 20:30:35 anyway, we have a way forward on this one. I think the proposed resolution reflects the consensus at the Forum alright 20:30:46 do we need to be detailed about the need for support? Can't we just say "we are asking for support to make this go"? 20:30:47 let's see how it flies 20:30:58 sdague: If we are planning to ultimately remove support, then I think deprecation is the right term. 20:31:02 cdent: yes, we need to be clear 20:31:04 i still see taking away seemingly arbitrary choices in deployment as one of the primary solutions we have for addressing the common complaints about complexity 20:31:06 because that's exactly the ask 20:31:12 * cdent shrugs 20:31:13 sdague: If we are saying, "pg is meh" then I don't think it is. 20:31:26 "tell me how much engineering budget I have to ask for for this feature to not go away" 20:31:53 smcginnis : i think "Deprecate" is appropriate signal if we want folks to wake up and pitch in 20:31:54 people did speak up saying "taking away an option i'm using doesn't simplify openstack" but of course having taken it away before they ever started to evaluate openstack likely would have simplified things for them later 20:32:06 I propose we continue the discussion on the review/ML. It's not as if the discussion was deadlocked there yet 20:32:18 fungi: right, and we right now aren't really being honest with folks 20:32:18 dims: Fair enough. It certainly conveys a greater sense of urgency. 20:32:27 #topic Next steps for "Describe what upstream support means" 20:32:33 #link https://review.openstack.org/440601 20:32:42 Do we still want this one ? 20:33:03 I guess I should follow up with johnthetubaguy 20:33:11 but maybe you have opinions 20:33:18 johnthetubaguy says on a recent comment that he's planning to update it next week-ish 20:33:35 oh I see it now 20:33:39 ok, let's do that 20:33:42 I'd say let him drive the discussion when he can 20:33:43 I think we do want this, to some extent. It relates to that discussion we had at the forum about explaining how things make it into openstack. 20:33:50 mixed feelings ttx, is a blog post enough to point people at? 20:33:59 dhellmann: sure, it feels very "opensource 101" to me 20:34:00 yeah, I think it's ok to let this one ride another week to see how things go 20:34:21 which I guess is fine, but seems odd to have to do it 20:34:23 it seems a useful statement to me at least 20:34:30 In general, do you feel like mixing discussion in Gerrit and ML is working ? Or should we have different types of discussions on each ? 20:34:37 sdague: right, and as you pointed out even the linux foundation had to explain that for a long time. I think we expected people to already understand it more than we should have. 20:34:44 though still not sure whether the project-teams guide might be a better location for that info 20:34:49 dhellmann: yep, good point 20:34:56 fungi : right +1 20:35:04 Asking because notmyname was wondering where to post (and ended up copy-pasting on both, which is a bit ineffective) 20:35:18 ttx: it's doubly effective! ;-) 20:35:19 ttx: I feel like the ML threads have brought people into the discussions that would have not otherwise 20:35:19 ttx: a comment as long as notmyname's really only needed to go on the ML 20:35:24 sdague : ++ 20:35:39 that was one reason I started the thread about binary packages there instead of directly with a resolution 20:35:41 dhellmann: agreed, it's actually kind of hard to ack in the gerrit review because you can't break it up 20:35:48 sdague: I guess we'll develop an habit about what fits on which 20:35:57 I honestly think they all need the ML threads 20:36:06 I think we should work out details on the ML, and refine language on the review 20:36:08 Ideally I would like the review to carry simple discussions and the ML to carry hard ones 20:36:14 going deep into policy in gerrit is hard 20:36:17 the current division/duplication between ml and gerrit comments seems likely to be a transitional state 20:36:21 dhellmann: yeh 20:36:37 But in the end we want our objection heard so we post everywhere 20:36:40 honestly, if the API Key thing had been only in gerrit, it just would have circled for 2 more years 20:36:46 which I find a bit ineffective 20:37:01 anyway, let's give it a bit more time 20:37:06 fungi: also, I agree, it's super early in the transition, new habbits have not yet formed 20:37:07 over time people seeing complex discussion limited to the ml will follow suit 20:37:12 #topic Change the target for this goal to uWSGI not Apache mod_wsgi 20:37:17 #link https://review.openstack.org/460951 20:37:19 ttx: I think you are right that it is transitional, but we will always have some overlap. 20:37:19 ttx: maybe the folks driving the "drop the meeting" stuff can write down some suggestions as part of replacing the stuff we have now 20:37:34 ttx: this one looks ready to approve 20:37:42 EmilienM: yes, approving now 20:37:48 +1 20:37:49 sdague: thanks for this change ^ 20:37:53 EmilienM: no prob 20:37:56 done 20:38:04 #topic Moving away from weekly meetings 20:38:06 with that in, the nova completion of it should hit this week as well 20:38:08 OK, several pieces 20:38:09 ttx: when do the new "wait a week" rules go into effect? I suppose we have to approve them first. 20:38:15 sdague: wouhouuu ! 20:38:18 dhellmann: exactly 20:38:23 * Stop requiring public IRC meetings 20:38:28 dhellmann: the last vote there was May 4 20:38:29 #link https://review.openstack.org/462077 20:38:39 oh, sorry, there were 4 today 20:38:45 * sdague bad at reading dates 20:38:52 Still think we need that one in before we start making changes 20:39:02 I like it 20:39:03 reflects current situation better anyway 20:39:31 Let me approve the sphinx cap now that it has two review 20:39:35 ++ 20:39:52 then we can recheck that one 20:40:16 folks can still vote, fwiw 20:40:19 but feel free to pile up votes 20:40:32 I would rather pass this one first rather than hold the rest of our community to a higher standard than the TC's 20:40:39 * Remove the proxying section from charter 20:40:44 #link https://review.openstack.org/463140 20:40:48 This one is I think a no-brainer. It's a charter change though, so we need 9 approvers 20:40:57 dtroyer: had a concern that other folks answered 20:40:57 +1 20:41:14 I just can't remember the last time we sued it 20:41:17 used* 20:41:24 (which is mainly the reason I proposed this) 20:41:33 Seems pretty much unnecessary at this point. 20:41:34 there have only been 2 votes in the last 6 months, right? 20:41:46 sdague: and none used proxying 20:41:49 and they were more about getting a sense of the room, and not binding 20:41:56 yes 20:42:00 At 9 approvals now. 20:42:02 we use Gerrit for all resolutions 20:42:02 my only real concern with this one is if we decided we needed to do something in an in-person meeting, but I think we'd want to move that decision out of the meeting anyway 20:42:09 ok, I'm on board now 20:42:14 dhellmann: yeah 20:42:16 ok, approving 20:42:32 dhellmann: yeah, decisions out of meeting 20:42:47 * Document voting process for `formal-vote` patches (https://review.openstack.org/463141) 20:42:55 This one is pretty close. Charter change, so also needs 9 approvers 20:43:05 #link https://review.openstack.org/463141 20:43:26 ttx I addressed the comments there 20:43:36 should be ok, except for the sphinx thing 20:43:39 yes you can pile up votes 20:43:47 I'll recheck it and all 20:44:05 do we have any other resolutions/motions up for vote we haven't brought to the mailing list? 20:44:41 just wondering if we're about to merge a process change that will cause us to instantly violate it with other votes currently underway 20:44:42 has this one been brought up there? 20:45:11 Not yet 20:45:25 maybe that should be brought as part of the "Drop TC meeting" thread 20:45:32 I think it was 20:45:40 in the drop tc meeting this was mentioned 20:45:46 ttx: I thought there was also going to be a waiting period *after* a resolution reached critical mass before landing 20:45:50 and it also triggered the work on this patch 20:46:04 sdague: sure, that's additional 20:46:13 sdague, I thought so, too 20:46:19 sdague: you have a minimal patchset-to-adoption delay 20:46:28 mmh, I don't recall anything about the waiting period after the critical mass but I guess we could add it 20:46:41 that was one of the concerns 20:46:44 oh, yeah, that was actually the concern I had 20:46:45 and you have a 2-3 day wait after it reached votes 20:47:04 people wait until some point, then the whole TC votes in 30 minutes and lands it 20:47:10 yeah 20:47:11 those two we have on the docket mostly reflec tthe current status 20:47:13 dhellmann: I must have missunderstood your concern. I thought the concern was to have enough time for voting and not really to check the patch until the critical mass was reached 20:47:19 should new resolutions link to the relevant ml thread(s)? 20:47:19 misunderstood 20:47:24 I can add that, it makes sense 20:47:32 fungi : good idea 20:47:35 fungi: yes 20:47:39 fungi: yes , like in commit message 20:47:52 a 7 + 7 rule (7 days minimum, 7 days after critical mass) 20:48:01 I also think the 5 votes for critical mass probably needs to change right 20:48:05 that was about quorum 20:48:07 that would slow a *lot*of things down 20:48:16 but with gerrit quorum is 20:48:19 just wondering if that prior discussion reference provision needs to be called out explicitly 20:48:22 sdague : so that's a minimum of 8 days but the average is going to be a lot longer 20:48:24 always 7, right? 20:48:33 dhellmann: yeh 20:48:37 well, I guess a min of 7 20:48:38 still 20:49:14 Ideally, the critical mass delay would apply to all resolutions 20:49:23 flaper87 : my brain is too fuzzy to help with wording right now, but maybe we can talk about it tomorrow 20:49:31 since people may object to what we consider trivial 20:49:45 heh 20:49:53 dhellmann: sure thing. I'll dump something and run it by you 20:50:08 so giving them all three day bake-time before pushing approve sounds reasonable 20:50:10 we can extend this a bit to cover fungi's concern and the delay after critical mass 20:50:23 ++ 20:50:51 anyway, that's other babystep changes 20:50:58 should not block the other ones 20:51:06 yes 20:51:07 sure, 7 seems most community friendly to give folks time to get engaged on things that are going in, 3 seems minimum acceptable 20:51:08 do we want to do this in steps, then? and approve this one? 20:51:22 dhellmann: yes 20:51:24 I'd honestly like some delay before this change, even if it's the 3 day one 20:51:46 sdague: sure, happy with holding. 20:52:00 It's just that as long as they are not passed we'll still have it the old way 20:52:06 which says 4 days 20:52:09 ok, let's move this one in 20:52:12 so.. incremental changes ftw ? 20:52:13 I had -W but removed it 20:52:17 ++ 20:52:22 I'll push another patch tomorrow 20:52:31 s/patch/review/ 20:52:45 flaper87: if sdague is uncomfortable with passing it now, I see no reason to rush 20:52:52 wfm 20:53:00 dhellmann: what wty ? 20:53:07 waiting works for me 20:53:10 ok 20:53:12 push it tomorrow, we vote, it lands by next session under the current 4 day rule, right? :) 20:53:21 I guess we'll wait 20:53:25 :) 20:53:29 My brain hurts. Remember its 11pm and I still fight with jetlag 20:53:36 it also tests doing it without needing a meeting 20:53:44 good point 20:54:08 happy with tarpitting those 20:54:10 * Drop Technical Committee meetings (https://review.openstack.org/459848) 20:54:11 not really, I don't think we can test this until this patch lands 20:54:15 anyway, let's wait 20:54:24 flaper87: I can just be slooow 20:54:27 ttx, best cure for that is some fine cognac.... 20:54:29 ttx: :) 20:54:38 ttx: so, this one we can skip today 20:54:43 flaper87: ok 20:54:48 #topic Open discussion 20:54:53 Anything else, anyone ? 20:55:02 nice seeing y'all last week 20:55:06 I suspect we'll still have a meeting next week ? 20:55:08 I'd like some more TC folks to weigh in on the thread about binary containers before I write a resolution 20:55:10 #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/116677.html 20:55:29 until https://review.openstack.org/459848 passes ? 20:55:42 dhellmann: it's pretty noisy already :) 20:55:44 dhellmann: btw, thanks for sending that out. I've been involved in this for a bit and it didn't occurred to me. I guess because I'm involved 20:55:49 at this point I'm still planning to write a "we don't publish binary artifacts" resolution 20:55:50 dhellmann: I found the thread hard to follow 20:55:54 dhellmann: I'm really mixed on that one. I'd like to have them, but I think the risks you pointed out are very legitimate. 20:56:06 dhellmann: I'd be happy with that, fwiw. 20:56:09 ttx: we could "skip" next week as an experiment :-) 20:56:11 dhellmann : even at release boundaries? 20:56:20 * fungi wonders if publishing wheels to pypi counts 20:56:40 fungi : that did come up. we don't call wheels "production ready" packages 20:56:45 dhellmann: we've had a lot in that thread already right? you, me, dims, fungi, ttx, smcginnis 20:56:49 I'm happy to consider the cargo-culted tradition of requiring a meeting before approving anything as dead 20:57:00 if everyone is comfortable wit hthat 20:57:04 ttx: +1 20:57:06 ttx: ++ 20:57:08 sdague: fwiw, I've commented on the thread already 20:57:16 sdague : maybe we're ready? I don't feel like I'm getting much feedback from the other perspective except "but this is what we want to do!" 20:57:16 flaper87: yep, and you :) 20:57:24 ttx: Is something happening next week? Why are we skipping? 20:57:31 sorry, I knew I was going to miss someone adhoc building a list 20:57:35 ttx: is that just part of the "let's do fewer meetings"? 20:57:42 don't get me wrong, I'm happy to skip 20:57:43 that's majority providing commentary 20:57:43 flaper87 : yeah, just fewer meetings 20:57:46 dhellmann : we can chat a bit if you wish before you start writing the resolution 20:57:50 flaper87: nothing happening. just asking 20:57:56 just want to make sure I'm not missing something important 20:58:03 sdague : fair, I didn't actually count, but didn't see some folks I expected to see 20:58:04 I can post a weekly report to try 20:58:14 I want to be everywhere, I'm supposed to be millennial, this is what we do 20:58:14 dims : sure 20:58:14 2 minutes 20:58:16 ok 20:58:17 dhellmann: worth poke people you want in there :) 20:58:18 * flaper87 chills 20:58:28 will likely post on Tuesday to keep the cadence 20:58:29 sdague : yeah 20:58:30 +1 for skipping 20:58:37 like mordred, I assumed to see him in there 20:58:38 we talked about starting a process of educating the board on better ways to ask the technical community to do stuff? Is there a next step on that? 20:58:39 darn, i was hoping we would wrap up early... given what we are trying to do with no-meetings 20:58:42 unless someone has a preference 20:58:54 cdent: dhellmann volunteered 20:58:55 cdent : ttx and I are supposed to start working on a draft of a presentation 20:59:02 oh, and me too 20:59:03 dims: :) 20:59:05 cool, just wanted to check that was still live 20:59:19 * dhellmann doesn't remember it quite that way, but ok 20:59:21 cdent : I'd be happy to have your help, if you have time 20:59:23 * fungi wonders what he's volunteered for last week and already forgotten 20:59:29 :) fungi 20:59:32 dhellmann: I can probably find it 20:59:36 fungi: that's why I started an org-mode doc :) 20:59:41 cdent : cool, I'll loop you in when we start 20:59:56 alright we are out of time 20:59:59 fungi, sdague: I use paper, so that if someone else forgets they don't have my notes 21:00:29 no meeting next week unless we end up absolutely needing one 21:00:34 #endmeeting