20:01:24 #startmeeting tc 20:01:25 Meeting started Tue Mar 14 20:01:24 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:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:29 The meeting name has been set to 'tc' 20:01:31 o/ 20:01:35 Hi everyone! 20:01:37 * lbragstad finds the next most comfy chair next to edleafe 20:01:40 Our agenda for today is at: 20:01:42 * mugsie lurks 20:01:44 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:49 We have three big sections 20:01:55 #topic New working groups 20:02:06 I'm a bit torn on those, as I really don't want to make it look like you need to apply to the TC in order to set up a working group 20:02:10 I mean, anyone should be able to form a group on anything 20:02:20 I get that a formal resolution gives the group some weight though, which is why the Stewardship WG was created from a TC resolution 20:02:20 (and in fact they do, often) 20:02:28 Opinions on that, before we dive in the specific requests ? 20:02:33 yeh, my feeling is people should just start gathering and doing useful things 20:02:39 +1 20:02:40 I generally agree 20:02:46 I don't want to make a resolution required 20:02:55 ttx: I can abandon mine if it makes no sense and just keep Wiki updated 20:03:04 but then I do like the TC saying something is important, and needs addressing 20:03:05 it feels like TC appoval ends up making these look like permanent institutions, vs. people coming together to solve things 20:03:10 any time we create a new list of things in governance, people will want to try to add to it 20:03:15 fungi: ++ 20:03:16 sdague: thats a good point 20:03:16 I guess the question to the authors is "what might make these worth the exception"? 20:03:17 EmilienM: we could maintain a registry of the workgroups but it feels overkill too 20:03:25 yeah 20:03:36 I do think there will be cases where we want to "charter" working groups, but both of these cases feel like we could skip that step 20:03:37 ttx: although the UC was talking about the issues they had without a registry 20:03:53 johnthetubaguy: ah ? 20:04:00 a registry makes a lot of sense to improve discoverability 20:04:06 a directory? 20:04:12 and that doesn't need to be in the governance repo 20:04:12 less official sounding 20:04:14 so, I think the real issues are, if people are coming together to solve a thing: a) how does anyone discover they exist? b) how would one get involved if they wanted to c) what do those folks see as their scope 20:04:16 them mentioned at the board meeting, they found it hard having no ... directory I guess 20:04:17 We could list them on the governance website 20:04:25 a registry for the uc is somewhat necessary, as it factors into their electorate 20:04:29 I mean a wiki page would totally work 20:04:30 but that means extar review 20:04:32 a wiki page solves it all except discovery 20:04:38 ++ 20:04:41 fungi: true 20:04:46 We can point to the wiki page from the governance website 20:04:54 we could link to the wiki from the governance site, or we could share a registry with the uc 20:04:56 avoids crazy reviewing 20:05:00 would we want to extend separate election privileges to "active" members of these working groups who are not already active technical contributors through other means? 20:05:01 ttx: yeah was about to type the same 20:05:03 If the need for a directory is partially driven by UC electorate concerns, might it make sense for the UC to perform the reviews to extend the directory? 20:05:19 persia : the uc has its own working groups 20:05:30 I like the combination of linking to the wiki from governance, it seems to strike the right official vs "just do it balance" 20:05:33 ok, let's dive into each specifically 20:05:39 #topic Propose VM and Bare-metal Platform Working Group 20:05:44 #link https://review.openstack.org/442387 20:05:47 johnthetubaguy: want to introduce this ? 20:06:01 so this really is an thing that keep coming up over beer 20:06:19 get a group to worry about the VM + baremetal platform 20:06:23 workgroups: no resolution needed, but beer welcome 20:06:30 :) 20:06:55 there are a few problems that keep coming 20:06:56 up 20:07:05 mostly user experience related 20:07:11 both in the human and machine case 20:07:21 humans using REST APIs, horizon, etc 20:07:21 sure, feels like a good vehicle to solve inter-project pains within that platform 20:07:26 it sounds like there are already people who worry about this, so the point is to just provide some rallying point for them? 20:07:44 yeah, its more about looking at the whole problem, and priorities between the efforts 20:07:57 fungi: also creates some inter-PTL agreement on priorities 20:08:03 one example, I think we should work together to work out what needs to happen at the forum for that set of use cases 20:08:04 how is this group different from the architecture working group? 20:08:05 * jroll sneaks in the back, late 20:08:18 on the topic of having groups be something that involves tc application: a win from that is that it is easier to get support from an employer to spend time on it when it is officially sanctioned 20:08:20 dhellmann: the main thing here, is the reduced scope 20:08:22 or API-WG ? 20:08:23 dhellmann: arguably a VM+Baremetal platform focused Arch WG 20:08:40 cdent : good point 20:08:41 (for the eaxmple of humans using a rest API) 20:08:44 johnthetubaguy : how are conflicting decisions between the two groups resolved? 20:08:57 johnthetubaguy : how does the TC stamp help? (curious) 20:09:00 discussions between the groups 20:09:05 cdent: could make it worth the pain of maintaining the list as a governance doc, good point 20:09:16 would everything the done by the PWG fall under the umbrella of the API or Arch WG? 20:09:16 so the TC stamp here, was more to identify a set of problems that need attention 20:09:17 dims : we've had plenty of companies only give permission for folks to work on "official" projects 20:09:18 johnthetubaguy: ok, so the API-WG started with a rough plan and 3 people 20:09:24 cdent: if it gets employer support to work more upstream, i'm happy to rubber stamp numerous taskforce resolutions ;) 20:09:25 dhellmann: I suspect conflicting decisions don't get solved 20:09:28 dhellmann : ack 20:09:37 sdague: yep, I think thats what this needs too 20:09:40 I guess my practical question is who are the key players here besides yourself? 20:09:42 ttx: or they come up to the tc? 20:09:47 dhellmann: yes 20:09:51 (sorry for making that statement after we had moved on a bit, but I had been pulled away momentarily) 20:10:13 because, I think we still have the johnthetubaguy's not allowed to sign up for more things by himself rule enforced on alternate tuesdays 20:10:14 sdague: not got commitment from folks yet 20:10:29 sdague: heh, that should be a thing 20:10:39 in the past, we've also said we wanted new groups to show that they're actually doing work before approving them. does that apply to working groups, too? 20:10:57 dhellmann: that makes sense 20:11:02 dhellmann: yes please 20:11:07 ++ dhellmann 20:11:14 so there is one piece that I wanted to check we are in agreement 20:11:17 and for the record, I think it's fine to have a group doing this, I just want to work out whatever approval process details we need worked out 20:11:19 the last thing I want to see is a ton of shadow governance locks on problems 20:11:30 right 20:11:46 at the same time I don't want to spend time vetting working groups 20:12:03 that doesn't seem like a good use of our time, no 20:12:05 they just should not exist if they are not doing things 20:12:31 to sdague's point, it would be unfortunate to approve a working group who ends up having no time to commit to the issue at hand, but ends up preventing others who are available from making progress on the same problem space themselves 20:12:32 right, which is why I kind of think staying out of blessing is best. It was a long time before the api-wg became "official" 20:12:35 so my idea was more to identify these problems need fixing 20:12:49 a resolution is probably a poor way of doing it 20:13:00 johnthetubaguy: that list of issues is a good one 20:13:13 it feels good if we as the TC can flag those things up 20:13:15 it may work better to start a ML thread and ask people who are interested in solving those issues to self-organize 20:13:25 dhellmann: ++ 20:13:29 johnthetubaguy: honestly, I'd be totally happy if we took that list of issues, made an attempt at 1-N prioritization 20:13:44 and if a collection of people show up to help there, ++ 20:13:46 johnthetubaguy: it feels like you should define your set of issues, start working... and if you need the TC to point to you and say: "that's a good thing" there are a variety of ways to do it 20:13:49 sdague: who is we in this context 20:13:58 sdague: yeah, in the working group, if it becomes a thing 20:14:07 right, if we need resolutions to codify specific decisions or something, we could do that 20:14:09 johnthetubaguy: well, you, and perhaps the TC stamping the issue list 20:14:27 ttx: yes, I was just wondering if we as a TC should do something to high light the issues, frankly this discussion is probably enough 20:14:44 perhaps simply making the "membership" or working groups fluid is sufficient to allow others to pick up the work without having to get some institutionalized group to relinquish it first? 20:14:46 sdague: OK, I see what you mean, propose the list, and maybe stamp it, that makes sense 20:14:47 i like the idea of TC saying this stuff needs attention 20:14:55 johnthetubaguy: you could request some time to present the WG issues to the TC and have some pile of +1s 20:14:57 because I think that's a very good starting point of key issues with the openstack platform 20:14:58 dims++ 20:15:00 dims: thats the bit I am wondering about how we would do that 20:15:02 iirc, last week the idea of some sort of priority list that wasn't tied to the goals process did come up 20:15:25 that aren't horizontal, or vertical, but much more usage based 20:15:26 johnthetubaguy: just ask for some time at a TC meeting and present* 20:15:40 then I'm happy to pile it +1s 20:15:40 and solving any single one of those would make openstack as whole better 20:15:47 ++ sdague 20:15:48 pile up* 20:16:14 so maybe the key bit I am getting here, is "this is not crazy" 20:16:20 we could also have that list of issues and "delegate" it to wgs 20:16:37 not crazy, but maybe we lack the framework to slot this and similar priorities into? 20:16:38 I will try run with this to the ML, and see if there is a motley crew keen to work on this 20:16:54 oh, yeah, the issue list idea came up with finding ways for new contributors to engage constructively, instead of through typo patches 20:17:05 I basically prefer that we support the WGs rather than bless them 20:17:13 ls 20:17:15 right 20:17:24 I quite like the flagging issues that need solving bit 20:17:27 * fungi certainly doesn't want to have to get ordained 20:17:55 johnthetubaguy: ok so next step is to raise a ML thread. We can discuss visibility of a WG registry separately 20:18:04 yeah, we should move on 20:18:17 and then someone needs to start a storyboard list of those issues :-) 20:18:25 #info Workgroup should get set up on the ML. TC is happy to supprot and encourage the work of the workgroup 20:18:46 I like this 20:18:48 johnthetubaguy : throw in a etherpad 20:18:51 ttx: +1 20:19:17 #info potential future work: how to maintain list of WGs and ensure discoverability, and a blessed list of high-value targets 20:19:36 #topic Propose Deployment Working Group (DWG) 20:19:40 #link https://review.openstack.org/442761 20:19:44 EmilienM: want to introduce this one ? 20:19:47 #action EmilienM to transform https://review.openstack.org/#/c/442761 into a ML thread to communicate about this new WG and what we plan to do 20:19:53 although I suspect it will meet the same fate 20:20:03 ttx: no need to spend time on it IMHO 20:20:04 it's like we just had most of this discussion already! ;) 20:20:20 EmilienM: for the record, I like that workgroup too. 20:20:33 ttx: ++, great start there EmilienM 20:20:39 I like the fact you like :) 20:20:44 it seems to already have more or less formed, based on discussions of related topics i've seen on the ml over the past couple weeks 20:20:47 we need more of those interproject groups 20:20:53 fungi: ++ indeed 20:20:55 yeah, seems like a good thing to do there too 20:21:13 ok, moving on 20:21:19 #topic Describe what upstream support means 20:21:21 #link https://review.openstack.org/440601 20:21:25 johnthetubaguy: you again 20:21:27 ttx: another justification for some sort of registry may be to know which groups to ask about PTG and Forum space 20:21:41 dhellmann: ack 20:21:42 it could still be a wiki page 20:21:43 dhellmann: i completely concur there 20:21:46 so this came up in the postgresSQL discussion 20:22:09 "supported upstream" is a strange phrase right now 20:22:16 so I attempted to write down some ideas 20:22:40 I like it -- still a bit of polishing work needed 20:22:45 seeing some good comments from ttx and dtroyer on there 20:22:59 I like the idea of defining the conditions for claiming support 20:23:11 avoids the weird "volunteer" mention 20:23:23 (although I see what you mean by that) 20:23:37 I totally stole the phrase from fungi as I couldn't come up with a better one 20:23:39 * dims has not reviewed that yet 20:23:47 i still like the word 20:23:52 should we just say "upstream support" then? 20:24:25 I also don't really want to get bogged down into listing all the requirements for support 20:24:30 volunteers may refer to the individuals, or to the employers who volunteer their employees' time to participate, after all 20:24:35 I was more wanting to baseline on definitions really 20:24:41 johnthetubaguy: yes, I like we keep it inspirational 20:24:44 fungi: totally 20:24:51 this feels a bit like "open source 101" 20:25:07 fungi: yes -- just know that some people will read it wrong 20:25:15 we have a disproportionately high number of users (and even contributors) who could use a regular support of "open source 101" 20:25:25 unfortunately ++ 20:25:27 agreed 20:25:28 er, regular dose 20:25:39 dhellmann: maybe, but its good to write down our shared assumptions 20:25:51 johnthetubaguy: maybe make it clear that this is nothing new, more of a reminder 20:25:59 johnthetubaguy : oh, I'm not objecting, just making the comment 20:26:02 ttx: yeah 20:26:13 all those people who think openstack is "like free vmware" are wondering where their support contract is 20:26:14 dhellmann: very fair comment too 20:26:14 more in the spirit of writing down our principles? 20:26:21 dtroyer: yep 20:26:41 on that note, is it really a "definition" rather than a resolution? 20:26:55 johnthetubaguy: hmm... wondering if it could fit in the project team guide... although I guess it's more directed to specific tactical groups 20:26:57 so lives near the principles not the resolutions? 20:27:18 anyways, answers on a postcard, I mean gerrit review comment 20:27:21 johnthetubaguy: I think it's a statement, not a living document 20:27:30 so I'd rather file it under resolutions/ 20:27:31 it seems reasonable to have a resolution saying "we're going to delete things when people stop contributing to them" 20:28:00 dhellmann: yeh 20:28:07 i think it's a statement at a point in time (resolution) which could be used to inform future updates to a living document such as principles et cetera 20:28:07 ttx: OK, I just never like trying to get things correct first time 20:28:14 ok, let's iterate on the review 20:28:19 cool 20:28:20 and move on 20:28:25 or even that we delete things that are considered debt if it helps us move the whole platform forward 20:28:34 johnthetubaguy: thanks for pushing those 20:28:50 sdague: didn't want to repeat the standard deprecation tag, but lets see what we come up with 20:28:53 because, I kind of think that's really what's behind the next one... 20:28:55 when you prune a shrub, you may lose a few live branches in the process ;) 20:29:11 sdague: yeah, thats totally why I raised this one 20:29:15 ooh, i got to write that down fungi :) 20:29:23 which brings us to.... 20:29:27 #topic Deprecate postgresql in OpenStack 20:29:30 #link https://review.openstack.org/427880 20:29:39 So this one is a bit stuck, although the previous resolution will help with it 20:29:45 I think there are multiple ways to slice this one 20:29:55 0/ Make a statement that we'll deprecate it unless there is more consistent upstream work to support it 20:30:02 1/ Pass a resolution now saying it's generally deprecated due to lack of upstream support 20:30:11 2/ Contract the "database" base service to the MySQL family (now or after the deprecation period) 20:30:20 (That last one would signal we can start breaking non-MySQL deployments) 20:30:29 Before we do (2) I'd like to give people a last chance to step up and save it. Maybe that's my soft side speaking though... 20:30:40 have we had any input at all from Huawei or SuSE? 20:30:46 you know how I said we should find a way to flag problems, how about we just say "the status quo of supporting many databases isn't working"? 20:30:48 Also before we do (2) I'd prefer non-MySQL numbers to drop below 5% (currently at ~10%) 20:30:50 I mean in the sense of their interest in supporting PG? 20:30:56 it feels like we've done that already, but not this formally? 20:31:02 ttx: ^^^ 20:31:07 Might be better to start with 1, with the statement that 2 will follow. 20:31:12 under 2/, are we feeling obligated to provide conversion/migration tools or instructions for people switching at upgrade time? 20:31:21 we haven't done anything formal. I guess the question is should we do (0) or jump directly to (1) 20:31:41 fungi : maybe 20:31:41 this proposal is basically (1) 20:31:45 I would pref to go straight to 1 to help signal "we mean it this time" 20:31:49 I don't see deprecation as a one way process, so I am fine with (1) 20:31:50 dhellmann: can we define what 'more consistent upstream work to support it' means? 20:31:50 ttx : i vote for (1) 20:32:03 gordc : excellent question. 20:32:29 it feels like more than one person asked "what consistent upstream work means", so (0) seems warranted 20:32:41 part of me things part of fixing this problem is digging deep to understand what the real issue is, and enumerate the possible solutions 20:33:05 although I wasn't involved in previous iterations of the discussion so I may ignore how many times (0) was already done 20:33:12 I also want us to answer clearly yes/no whether we *want* that contribution, or if we're more interested in dropping support than having help with maintenance. 20:33:24 i do feel like we're still operating a little on the misconception that it was already broken when we stopped testing it. i stand by the reasons for ceasing testing, but there were no outward complaints of breakage until the issue ceilo hit recently 20:33:28 dhellmann: right, I think we don't want that contribution 20:33:34 dhellmann: I don't think we can, till someone has all the options laid out 20:33:46 fungi++ 20:34:02 sdague : how do we determine consensus on that? 20:34:34 I think we need to do (1) before we make that decision 20:34:41 johnthetubaguy : aren't the options (1) someone says they will work on gate failures and we support pg or (2) we do not want anyone working on gate failures, pg is going away? 20:35:09 dhellmann: its more about how you avoid the gate failures in the first place, not working on that seems bad at this point 20:35:11 that's two different ways of writing (1), for sure 20:35:13 johnthetubaguy, ttx : option 1 presumes we would want support if someone showed up. We should not ask for help if we're going to turn people away. 20:35:15 my slightly snark answer to gordc's question is: 20:35:34 dhellmann: + 20:35:42 when pg folks implement consistent unicode name support for both mysql and pg across the starter kit 20:35:46 the real option 1 seems to be that we do not want to support it because we want to use $features of mysql 20:36:04 because the issue is that the community has to pay a pg tax on every feature, even if a small one 20:36:19 we have to signal that we are "contracting" the options 20:36:22 its more about stopping trying to think about all these different database on every patch, somehow 20:36:33 sdague: cool, i dont know what that issue is personally. but good to have some qualifer 20:36:34 and saying that pg folks only need to be engaged when it's entirely their platform at issue, instead of helping on general things to pay back that tax 20:36:38 dims: +1 thats why I want (1) to start the deeper discussions 20:36:46 sure, but then let's be honest. it's not about lack of support from anyone in our community, right? it's about a fundamental underlying difference in the database engines. 20:36:48 dims: I don't think we should contract until the alternate option is below 5% though 20:37:03 I mean... open question 20:37:16 dhellmann: right, it's based on the fact the dev community and operator community largely has the skills knowledge on one backend 20:37:21 what's the adoption bar under which it's fine to contract ? 20:37:33 20% ? 10% ? 5% ? 20:37:42 dhellmann: tbh, i don't think we can accept/support pgsql if there is no gate on it since it's going to be impossible to measure if it's maintained or not. 20:37:44 and "make it work for this other one too" is a real cost, even just at coming up with base plans 20:37:48 PG is currently ~9% of deploys 20:37:48 sdague : are the unicode issues addressable via sqlalchemy, for example? 20:37:53 dhellmann: no 20:38:06 there was a distinct impression in the joint board/tc/uc meeting last week where the ecosystem perceives openstack as complex, and overall we need to shed some weight (in terms of providing deployers/users too much flexibility) to simplify it 20:38:13 fungi: ++ 20:38:23 fungi: ++ 20:38:27 yep fungi 20:38:30 fungi ++ 20:38:40 sure, I don't have a problem with that, I just want us to be honest about the reason we're doing it. 20:38:45 easy ways include removing backend options where the ecosystem has already mostly chosen a winner 20:38:56 so the request for help is helping people move between databases? 20:38:59 yes, we shouldn't say it's for lack of upstream commitment then 20:39:06 and thos in particular seemed like a fairly clear-cut example of that scenario 20:39:11 s/thos/this/ 20:39:14 which makes johnthetubaguy's resolution a bit redundant 20:39:29 johnthetubaguy : would we accept features in service projects to ease that migration? like some sort of db-neutral dump and import tool? 20:39:31 well, irrelevant I guess 20:39:34 we can cite both reasons ttx 20:39:41 right, and hopefully prevent more people from being on the "wrong" side of a "don't worry wesley, likely to kill you in the morning" 20:39:46 dhellmann: thats the kind of thing I was thinking 20:40:02 dims: I would argue it should just be submitted as a base-services.rst patch then 20:40:03 * dhellmann has a use case for that tool independent of a db transition 20:40:24 dhellmann: maybe os-ops scripts that use some alembic magic, but something 20:40:25 ttx : agree 20:40:35 dims: no need for a resolution citing lack of commitment if we'd do it anyway in the name of contracting options 20:40:40 because I suspect that suse and huawei ended up over on that side of the line based on us not being properly expressive that there was a preference here upstream 20:40:41 johnthetubaguy : I want it to be schema-neutral for my use case, too 20:41:10 sdague : exactly. let's not make it worse by suggesting there is any amount of upstream commitment that could reverse this course. 20:41:15 sdague: not really from huawei pov. 20:41:18 did we get explicit about rabbitmq already? 20:41:32 johnthetubaguy: nope 20:41:52 johnthetubaguy : we can line both up :) 20:41:55 johnthetubaguy: the non rabbit solutions hard failed enough that a resolution was never really needed practically 20:42:09 sdague: true, but its good to let folks know that 20:42:10 there are people actively working on zeromq, and maybe other drivers 20:42:33 dhellmann: maybe its time to tell them to stop that (unless it fixes rabbitmq ha) 20:42:40 so we need to engage those teams when we start talking about deprecations there 20:42:42 dhellmann : mirantis has stopped work on zeromq 20:42:54 dhellmann: it fixes a specific distributed cloud case 20:42:57 dims : ok, I thought it was someone else 20:43:11 different discussion though 20:43:16 ttx: right, my point is someone still thinks there's active work to be done there 20:43:34 feels like they should both get the same treatment 20:43:50 I think that is a reasonable starting point 20:43:56 "hey we tried to abstract this stuff, we failed, sorry" 20:44:06 we'll want to consider the rpc and notification cases separately, I think, but yeah 20:44:21 we're also investing in amqp driver (without rabbitmq) in tripleo 20:44:23 OK, so two different facets to polish: be clear why we are doing it to not open false hopes, and also be clear of when we'd be fine with breaking setups (after deprecation period I guess) 20:44:25 dhellmann: thats true, I was thinking RPC 20:44:26 which would solve the rabbitmq ha 20:44:30 johnthetubaguy: or more importantly, the abstraction isn't going to make anyone really happy 20:44:59 sdague: true, thats realisation here really 20:45:00 ttx: and suggest that folks start thinking about transition plans, and encourage project teams to allow feature additions to support that transition. 20:45:07 johnthetubaguy: I prefer to see it as the natural end of an expand/contracting of options, once the market /operators picked a winner 20:45:17 not a failure in abstracting 20:45:54 anyway, I think we know what to work on to improve the proposal(s), let's move on to next topic 20:46:09 ttx: maybe... a bit of both for sure 20:46:12 johnthetubaguy : that last thing I said may be something to add to your resolution (that we'd want projects to build transition tools) 20:46:23 #info two different facets to polish: be clear why we are doing it to not open false hopes, and also be clear of when we'd be fine with breaking setups (after deprecation period I guess) 20:46:30 dhellmann: I think thats covered in the deprecation tag already, but I will check 20:46:40 johnthetubaguy : ok 20:47:07 #info if we'd do it to contract options, maybe the resolution on upstream support is unnecessary 20:47:13 #topic Status update on other proposals 20:47:19 Let's go quick on those 20:47:26 * Golang CTI (https://review.openstack.org/410355) and Dims's Small steps for Go (https://etherpad.openstack.org/p/go-and-containers) 20:47:27 dtroyer, dims: quick update ? 20:47:50 I rev'ed the CTI doc Friday, think I got the comments, and see one last tab fail on my part 20:48:10 we have a git repo for golang-commons for oslo style ini and logs. trying to rustle up some contributors 20:48:13 golang-client is current on the proposal (as far as it goes) for a real-world example 20:48:33 ok so still WIP 20:48:51 I have a quick question on this topic 20:48:52 dtroyer: let me know when ready for formal vote 20:48:57 notmyname: sure 20:49:32 ttx: there are a few details to be added, but the only thing really missing from the CTI is a translation story 20:49:41 does the TC want to see the dims/dtroyer work happen before anythign else? how does it fit with the things in the flavio resolution? what order does the tc want to see things happen in? 20:49:51 dtroyer : k8s folks are struggling there too 20:50:13 dtroyer : translation may not be a high priority unless the i18n team is planning to change their scope to include non-ui tools 20:50:16 dtroyer: dims no gettext support in Go? 20:50:34 clarkb : tools around it 20:50:37 notmyname: I think flaper87's framework calls for approval of the technical case before we work on how that would work 20:50:38 also we should be pretty up-front with reasons golang-client is not a replacement of gophercloud. we already have enough reputation problems outside our community when it comes to reinventing other people's wheels 20:50:41 clarkb: honestly I haven't spent more than an hour on it so far, so IDK 20:50:57 fungi : right 20:51:03 notmyname: here they started working on part 2 assuming you would file something 20:51:07 I think 20:51:13 dims: ? 20:51:31 I added a short history of that to dims' etherpad, and am using it here because it existed and I already had core on it and could iterate quickly wihtout impacting anyone else 20:51:47 we've held off once the new ML thread and proposals started 20:51:55 #link https://governance.openstack.org/tc/reference/new-language-requirements.html 20:52:04 (I feel like we went over the technical use case for Swift already, but we could use some formal stamp) 20:52:14 notmyname : i'd like swift team to help with the golang-commons if possible 20:52:33 ttx: +1 I was going to check the same thing 20:52:55 fungi : +1 20:52:55 it was unclear to me if the "why not gophercloud?" question was answered? 20:52:56 dims: from what I've seen, the new golang commons thing looks like a client tool? which was never under the no not python rule 20:53:02 which was somewhat confusing 20:53:03 cdent: me too 20:53:21 figuring out the ci and stuff like that is good, but the specifics seemed tangental 20:53:35 notmyname: so we still need some "use case analysis" around swift to be approved. I don't think you need a lot more than what you already presented, but we need it to go through the new proces (and be approved rather than rejected) 20:53:56 I suspect dims will help you do that 20:54:12 ttx: yeah, and we're planning on that. but my question is if the tc wants to see that before or after the current dims/dtroyer work 20:54:13 (assumed that was in progress) 20:54:21 I would say before 20:54:22 notmyname : it's not a client tool, it's code that can help with standardzing some of the operator visible things like logs and ini files 20:54:34 based on "step 1" in that document coming before "step 2" 20:55:01 need to switch to open discussion, as I had a couple topics to cover there 20:55:13 ccdent, mugsie: let's talk in -dev after this if I can answer more 20:55:21 ttx: ack 20:55:27 we can continue in #openstack-dev the discussion between dims and notmyname 20:55:31 #topic Open discussion 20:55:36 I have two topics to cover 20:55:39 #info Encouraging Forum brainstorming 20:55:48 Looks like we have a lot of "we could discuss this with operators at the Forum" moments, but not so many translate into ideas on the etherpads 20:55:51 #link https://wiki.openstack.org/wiki/Forum/Boston2017 20:56:01 Last week we discussed using the Forum to fill the missing link between user stories and implementation ideas and complete the feedback loop 20:56:06 (in particular build up-to-date gap analysis by involving developers in the discussion) 20:56:16 It feels like email reminders are not really cutting it, so I'd like to encourage you to get personal 20:56:24 try to encourage people to think about and post discussion topics ideas 20:56:36 Plan was to start filing formal topic ideas next week, so that the committee would be able to select a schedule for first half of April 20:56:43 The deadline was pushed back one week 20:56:57 (initial deadline was ~today) 20:57:03 But maybe the whole timing is too short, I don't know 20:57:37 it feels quite soon after the PTG, but having the topics soon helps with requesting budget to attend 20:57:49 the mysql/pg and messaging deprecations should go on that list 20:57:51 yeah, wondering if the whole timing is not just too short 20:58:04 goal was to publish schedule a month early 20:58:07 (before the event) 20:58:42 ttx: I totally missed we had a deadline, I probably did know, but I think my head is assuming we sort that all much nearer the time 20:58:43 I don't see a list from the Arch WG, is there one somewhere? 20:58:45 on one hand we want time to figure out which topics are interesting, on the other we need the schedule published so people realize what will be discussed 20:59:03 ttx: I don't have all the specs approved for this cycle yet, so I am not totally thinking about next cycle 20:59:05 dhellmann: I posted mines on the TC catchall 20:59:21 My other topic was around Vision exercise feedback 20:59:37 we can cover that one next week 20:59:53 I have a photo with 6 bullet points on it, that looks good 21:00:12 ok, we are out of time. 21:00:20 Thanks everyone! 21:00:34 if folks get a chance look at https://github.com/Jermolene/TiddlyWiki5/pull/2371 21:00:36 let's overflow to #openstack-dev 21:00:41 whoops not that! 21:00:43 thanks ttx 21:00:45 #endmeeting