20:01:42 #startmeeting tc 20:01:43 Meeting started Tue Aug 2 20:01:42 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:46 The meeting name has been set to 'tc' 20:01:48 Hello everyone! Our agenda for today: 20:01:53 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:55 * flaper87 bows and says hi 20:02:03 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:02:16 ++ 20:02:17 #topic Limited Use of Alternate Programming Languages vs. Policy and process for alternate programming languages 20:02:28 (NB: if the discussion gets too noisy we might switch to voice turns, but let's try simple first) 20:02:35 We have two proposals on how we could selectively allow alternate programming languages 20:02:41 #link https://review.openstack.org/339175 20:02:45 #link https://review.openstack.org/346243 20:03:02 The first one from dims I would summarize as "allow selectively after analysis" 20:03:14 The second one from notmyname I would summarize as "allow by default, get progress reports, potential veto before merge" 20:03:16 * edleafe_ reads on his phone 20:03:30 Both introduce the concept of two tier of languages (official/supported vs. alternate/unsupported) as a way to clearly state what the "default" languages are. 20:03:39 that was my understanding of each as well 20:03:48 good summary ttx 20:03:51 Both assume that we actually want to allow usage of such alternate languages whenever that usage is "warranted" (i.e. when the default languages can't be used to solve the issue at hand) 20:04:01 (rather than, say, find a way to artificially keep things written in another language outside of official "OpenStack") 20:04:15 So maybe we should first discuss that (agree on the end goal), and if we do, then discuss the less painful and most efficient way to reach it 20:04:20 o/ 20:04:25 o/ 20:04:31 (i.e. the best way to discourage gratuitous usage of alternate languages and limit team frustration when rejected) 20:04:43 So question to TC members to kick this off: how much do you like the idea of allowing usage of alternate languages whenever that usage is "warranted" ? 20:05:13 ttx: define warranted 20:05:30 that's my issue with proposals like that because it's always kinda subjective 20:05:33 not much. My concerns remain and I think we'll have a hard time defining warranted objectively 20:05:36 mtreinish: as defined above: when the default languages can't be used to solve the issue at han 20:05:38 d 20:05:41 one thing to add ttx, in my proposal, TC acts as a gatekeeper for new languages and the cross project team acts as keeper for allowing projects to use the blessed languages on a need basis 20:05:46 My concerns == community impact 20:06:36 i like the idea of allowing usage of alternative languages when warranted. (for some definition of warranted) 20:06:37 flaper87: community impact on the project or on openstack? 20:06:44 gordc: both ? 20:06:44 gordc: openstack 20:06:52 but yeha, mostly openstack 20:06:56 gordc: both 20:07:03 ack. 20:07:16 johnthetubaguy seems +1 on the intent if I read his comments correctly (he had to drop off the meeting) 20:07:36 so ... I don't have well structured thoughts here, even though the topic has been lurking for quite a while now 20:07:45 my reluctance to take this path is still based on the teams asking to go first. One team hasn't demonstrated to me that they need to use another tool, and the other team hasn't demonstrated that they have the community commitment to be the right group to establish best practices for a new tool. 20:07:47 how are we going to track the dep trees of these new languages, will this need to be done in requirements? 20:07:58 after a quick skim of the current state of both specs, i don't see a clear and objective definition of how the TC can decide what is or is not "warranted" 20:08:00 if it's openstack, i'm assuming it's always going to have some non-trivial impact. 20:08:03 hasn't the idea of alternate languages already come up when javascript was added to python? 20:08:49 notmyname: no, not really 20:08:50 notmyname: I think it was more discussed when we decided to keep Horizon "in" OpenStack 20:09:03 javascript is not an alternate language for writing openstack services 20:09:03 and JS being grandfathered in as a result 20:09:16 mordred: ++ 20:09:19 to me, the line is about REST API services also 20:09:21 I do not think JS and openstack is a relevant comparison, grandfathered or no 20:09:23 mordred : ++ 20:09:24 mordred: horizon isn't an openstack service? 20:09:24 yeah, I don't place Go in the same group as JS (or YAML for the matter) 20:09:25 annegent_: yes 20:09:36 the "pain outweighs gains" warranted line 20:09:37 notmyname: it does not implement a server process in javascript 20:09:42 basically we have one language for one task currently 20:09:44 er, maybe I mean that the other way 'round 20:09:44 well, just to play devils advocate ... there is nothing in the policy that blocks a nodejs server project ... 20:09:50 notmyname: it uses javascript in browser to interact with the REST API it has that is written in python 20:09:51 mordred's point is key -- and also goes to the other languages in your proposal, notmyname 20:09:59 mugsie there is policy that blocks that now. 20:10:03 bash and yaml are languages, sure, but have not been used to write an openstack service 20:10:17 we have PLENTY of non-python code in openstack 20:10:29 I think my point is that the supported language set used to be len 1, and now it's len > 1. so the idea of "only python is sufficient for openstack" seems to have already been crossed off the list 20:10:33 devananda: if you write an openstack service in yaml (only), I'll be so impressed. 20:10:35 #link http://governance.openstack.org/resolutions/20150901-programming-languages.html 20:10:44 all of that code is in service either of specific communities (ruby for puppet/chef) or domain specific piurposes (browser actions) 20:10:59 notmorgan: I need deva doing useful things, please don't challenge him :D 20:11:00 yes, so there seems to be room for allowing extra languages whenever Python can really not be used (think JS) 20:11:05 notmyname: I can see why you'd think that, but I disagree 20:11:13 jroll: but I kinda want to see a service all in yaml too :) 20:11:19 notmyname: and I refer to my previous 2 sentences 20:11:20 jroll: *shiftyeyes* 20:11:27 hah 20:11:51 could we cut the chatter today, please? 20:12:01 * edleafe is back home 20:12:15 dhellmann: ++ 20:12:35 * jroll apologizes 20:12:38 The way I see it, we are OK with adding languages where Python can't be used. If Go was used to implement a piece that handled disk i/o in Swift I think we wouldn't have the same discussion -- the issue here is that it also is used for code that we usually run Python for (the REST API) 20:12:41 ttx: are we waiting for other votes from other TC members? How can we move the discussion forwarD? 20:12:42 ops 20:12:46 you faster than me 20:12:57 it has been and continues to be my position that if we're going to start rewriting parts of openstack services in not-python, it should be as part of an effort to completely rewrite everything 20:13:12 ttx: an internal api that happens to be rest-ish right now and may or may not be in the future 20:13:16 hence the risk of contagion to other services and the threat of gratuitous usage 20:13:25 and if we were rewriting everything, i dont' think language would be problem #1 to deal with 20:13:35 it is my opinion that the cost of just having some bits of some services in python and some in go is not a clear enough win to justify the cost 20:13:36 so, is the problem the people who asked to use the language, or the possibility of the new language. the former seems to be the bone of contention for some people 20:13:41 ttx: that's what we've been working on in swift in golang 20:13:46 notmyname: good point -- do you mean there wouldn't be a rewrite of the proxy server in Go ? 20:13:53 russellb: +1 20:14:05 russellb: ++ 20:14:33 ttx: I'm not interested in that right now. IMO there's a ton of other stuff we should be focusing on, and the ecosystem cost to dropping python (actually, wsgi) from the proxy server would be huge 20:15:06 ttx: clarification: I'm not interested in a golang proxy server. I am interested in this discussion and your thoughts 20:15:09 flaper87: to answer your question, I want to have an idea of how much we support the end goal of those two proposals. We ended up the previous run with the idea that we could explore selectively adf 20:15:13 adding* 20:15:19 rather than blanket adding 20:15:28 as from the thread kevin fox posted on issues that pre-date big tent ... there are some other priority technical issues to be dealt with 20:15:31 Those two proposals propose selective add 20:15:53 so are we ok with that goal ? No point in debating the details of each if we aren't. 20:16:11 mugsie: good question :-) 20:16:16 Personally I'm fine with the idea, but would like the implementation to prevent contagion 20:16:23 ttx: I am not on board with that goal, personally, no 20:16:26 ttx: you might want to use a #vote here, I guess 20:16:32 That way I think it'd be clearer 20:16:36 so, consider me in the "no, I don't think it's worth debating details" camp 20:16:39 ok, let me set that up 20:16:43 and it'd also stay logged/summarized 20:17:07 fwiw, I am still not convinced we need to add another language, like Go, within the openstack namespace, for implementing components of the services that a) are implementable in python b) could be implemented as an external library and then consumed by existing python 20:17:25 I'd also try to avoid the "if warranted" part in the question as that's, imho, not relevant to this vote 20:17:36 flaper87: ++ 20:17:45 I'd also say I'm unconvinced of a warranted need for a service rewrite in Golang. 20:17:53 flaper87: ++ 20:17:58 #startvote Do we agree with the end goal of selectively allowing extra languages in OpenStack whenever Python ends up not being not the optimal tool for the task? yes, no 20:17:59 Begin voting on: Do we agree with the end goal of selectively allowing extra languages in OpenStack whenever Python ends up not being not the optimal tool for the task? Valid vote options are yes, no. 20:18:00 Vote using '#vote OPTION'. Only your last vote counts. 20:18:02 devananda: +1 20:18:06 does that work ? 20:18:10 ttx: actually ... 20:18:16 I think it would be worth being clearer 20:18:22 #undo 20:18:23 Removing item from minutes: 20:18:36 since as notmyname points out we already have other lnaguages 20:18:37 you might have to endvote first? that removed a link... 20:18:37 heh, that undo didn't quite work .. 20:18:38 #endvote 20:18:38 Voted on "Do we agree with the end goal of selectively allowing extra languages in OpenStack whenever Python ends up not being not the optimal tool for the task?" Results are 20:18:43 sigh 20:18:53 #link https://review.openstack.org/346243 20:18:55 le sigh 20:18:58 I think the thing we're talking about is specifically key/necessary components of services 20:19:07 "Do we agree with the end goal of selectively allowing extra languages in OpenStack?" 20:19:08 #link http://governance.openstack.org/resolutions/20150901-programming-languages.html 20:19:25 mordred: propose alt text 20:19:30 "Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purposes of writing services?" 20:19:36 mordred: ++ 20:19:46 * devananda deletes what he was typing 20:19:48 mordred: ++ 20:19:50 "when absolutely necessary"? :) 20:19:54 mordred: dedfine services, as the objectserver is an internal node in Swift... would that count ? 20:20:00 ttx: yes 20:20:05 Would the dns proxy from designate count ? 20:20:09 "However we should not limit OpenStack service projects to these three programming languages in the future, as it would either mean using suboptimal tools, not being able to address specific problem spaces, or artificially excluding specific project teams." 20:20:10 it's a key/required part of the swift service 20:20:22 russellb: three? 20:20:36 devananda: quote from the resolution dhellmann linked, bash/JS/Python 20:20:43 that hummingbird is not the rest api itself does not make it any more essential in a world where it's merged, to swift as a service 20:20:48 mordred: ok, so services/nodes 20:20:50 s/more/less/ 20:21:00 let me cast that one 20:21:01 sorry for that mistype -it really does change the meaning of the sentence 20:21:06 ttx: miniDNS is also a required sub service of designate 20:21:21 mugsie: we do not write miniDNS 20:21:27 designate does 20:21:40 oh - is that the go dns thing? 20:21:51 designate-mdns is (currently) a pythoin DNS server 20:22:00 so yes - I agree, it's the equivilent example 20:22:00 mdns stands for miniDNS 20:22:18 is miniDNS something that can be reviewed and packaged separately? 20:22:28 #startvote Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purpose of writing services? yes, no 20:22:29 Begin voting on: Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purpose of writing services? Valid vote options are yes, no. 20:22:30 Vote using '#vote OPTION'. Only your last vote counts. 20:22:39 #vote no 20:22:41 #vote no 20:22:43 #vote no 20:22:46 #vote yes 20:22:48 annegent_: this was our proposal to have the separate swift component written in go be packaged separately. 20:22:51 #vote yes 20:22:58 #vote no 20:23:00 #vote no 20:23:03 #vote yes 20:23:05 (for some serious amount of "selectively" 20:23:06 ) 20:23:10 #vote no 20:23:31 * edleafe wishes he could vote... 20:23:37 #vote no 20:23:48 #endvote 20:23:49 Voted on "Do we agree with the end goal of selectively allowing extra languages in OpenStack for the purpose of writing services?" Results are 20:23:50 yes (3): dims, ttx, russellb 20:23:51 no (7): annegent_, mtreinish, thingee, sdague, mordred, dhellmann, flaper87 20:24:00 OK, so far from consensus with heavy leaning on NO 20:24:10 My next question then would be... 20:24:23 How do we address Swift needs ? What is their next step ? 20:24:43 fantastic question 20:24:43 They clearly rujn into an issue where Python don't get them the disk i/o behavior they need 20:25:02 ttx: when this was originally proposed, the TC recommended it be packaged separate for the component that warrants a different language. 20:25:12 artificial code split of in/out of OpenStack is kind of lame IMO... 20:25:18 russellb: ++ 20:25:18 russellb: ++ 20:25:19 Wasn't the suggestion that hummingbird be packaged separately rejected becuase it would "fracture the team"? 20:25:25 yes 20:25:31 russellb: so is an inconsistent policy in this case. 20:25:32 russellb: yes, I'm not happy with that solution either 20:25:32 thingee: that has been my suggestion a couple times, but it creates a significant impact on any developer(s) writing the go-side of that 20:25:59 All those who voted no, would the "external" development be your answer to the "next step" question, or do you have other ideas ? 20:26:27 devananda: for the folks who have leaned on separate packaging, it was to reduce the impact by having it be on a project, not the entire community. 20:26:37 beyond the team impact (which would be huge), it would also have a significantly high technical cost, and beyond that, it would force us into a situation of presenting to users an upstream "openstack" version that isn't supported/maintained or just flat out missing 20:26:49 ttx: IFF the external development item can be installed via normal distro package mangaers in a way that allows for pip + other-requirements to express the need 20:27:28 notmyname: there are lots of requirements that are used by projects that are not part of OpenStack 20:27:35 does "external" development mean completely outside of the openstack namespace? 20:27:40 ttx: if the thing is an external component that is onlyu installable by cloning a git repo and running a build process somewhere, I do not think that would be particularly useful 20:27:42 that doesn't make them any less 'upstream' 20:27:44 tdasilva : no 20:27:45 tdasilva: no, just outside of TC's reach 20:27:48 ttx: that would be the solution I'd propose too. 20:27:57 so smae tooling 20:28:06 tdasilva: CI/gerrit/etc will still be available 20:28:13 which kinda reduces the technical pain, but the lameness stays imho 20:28:26 so we would break apart a repo like openstack/swift and openstack/hummingbird just because....seems really lame 20:28:36 for me it’s not just about hummingbird, it’s about losing the thing that has made openstack work as a competitive maketplace of ideas. tools will change and grow. many of the things we use for our great development process around python didn’t exist in their form before we put them together over the last few years. future innovation is going to happen in languages other than python and that can happen in openstack or 20:28:36 outside of openstack, wherever those contributors feel welcome 20:28:36 lame++ :) 20:28:41 i will give an example from designates side - for us to add a new record type (A, AAAA, CNAME, etc) we would have to release a version of designate that created the tables, then a version of mdns that could render it to wire format, then a version of designate that used the version of mdns with tghe new code 20:28:47 same tooling, with the end goal of being packaged by various distros and installable via apt/yum/... would be technically feasible and yet still alienate that team 20:28:57 jbryce: ++ 20:29:22 another option is to write performance critical bits in cython or something similar 20:29:28 sometimes it feels to me like when a proprietary company gets really stuck on the decision of what to do when they have a cash machine on an existing product while facing a disruption from a cheaper competitor 20:29:49 There is another solution, which is to grant Swift a specific exception, but it's also lame because it's just one more way Swift is special, and this time it's not coming from them 20:29:50 mordred: the thing is, developers in our community already wrote a more performant version. they wrote winning code and a winning implementation 20:30:01 mordred: that is the normal pattern for something like this 20:30:06 mordred: that is a possiblity - but are we allowed? 20:30:19 its C, whihc is not on the list 20:30:38 mordred: you could write them in go and compile to a Python module 20:30:43 which comes back to the "ever have a new language vote" that just happened 20:30:47 right, not sure why that's different or better (Python C bindings) 20:31:10 if you're setting the expectation of non-python projects in infra as non-openstack projects, what kind of priority level for support will there be for breakages? i would implicitly assume it's less than official projects? 20:31:40 dougwig: best effort I would say, yes 20:31:46 which some of the critical gate infra structure might rely on 20:32:22 the thing that can keep an open community from falling into that proprietary company trap (milk the cash cow or disrupt yourself because someone else will do it if you don’t), is that we don’t have the income imperative and we can develop these technologies in the open and see which approaches are working or not. 20:32:28 i.e. if there is a bug in hummingbird and it is an unoffical project - but it blocks the gate for $reason - what do we do? 20:32:35 jbryce my sense is that it's the plugability that I struggle with. If you can't make the golang piece plugable it means you're abandoning the other service implementation? 20:32:42 mugsie: actually, cythion is done in a python syntax, and pip/setuptools deals with it just fine 20:32:44 so to me it's still 'python' 20:33:08 mordred: OK, I would not have made that distinction. 20:33:28 jbryce which is what I read from notmyname "presenting to users an upstream "openstack" version that isn't supported/maintained or just flat out missing" 20:33:32 jbryce: I hear that argument, I really do. I'm not ignoring it. just in my personal best judgement it is not currently worth the pain 20:33:40 jbryce it's still too black and white. 20:34:11 my concerns about doing this, in this way, starting with this team, are too long for irc, so: http://paste.openstack.org/show/545744/ 20:34:25 My desired outcome here is that we find a solution for Swift that lets them use the tech they need, but without creating a contagion effect of gratuitous rewrites throughout OpenStack services. I'd also like an outcome where other Python coders in our community would go and help Designate write their stuff in Python (or allow them to use Go too if that ends up not being possible, but I don't 20:34:27 believe in that). Feels like I'm a minority though 20:34:49 jbryce: I do not believe we have achieved the success we have achieved by letting everyone do everything in whatever way they feel. in fact, I think we have achieved success in spite of the amount of divergence we already have. I do not believe introduction of more divergence will lead to greater success 20:34:55 #link http://paste.openstack.org/show/545744/ 20:34:59 ttx: i'm with you. 20:35:13 that is, of course, merely my point of view, and as always, I'm happy to defer to others happily should I wind up to be wrong 20:35:30 dhellmann: so, your conceres are still the teams, not the "should we have another language" ? 20:35:33 but i'm not getting the feeling that any positions are changing here 20:35:35 concerns* 20:36:01 mugsie : both, but this is why I'm comfortable sticking with "no" for now 20:36:28 jbryce: innovation is happening in many languages, not just golang or python, but our development process/tooling is, as you pointed out, pushing the envelope of what can be done with python. allowing in another language doesn't immediately create the same benefits for that languages' developers 20:36:46 mugsie : all of the community division and technical divergence concerns I have would be addressed better by a team that had proven willing to collaborate on those areas in the past 20:36:51 mordred: I think I mostly agree with you there, especially as someone that has wrangled with a lot of that divergence (though less so than dhellmann) 20:37:07 devananda: jbryce: My fear; and I think the underlying fear in jbryce's comments, is that we'll lose smart folks who want to point their brain in that direction, rather than winning them over to the "OpenStack way" 20:37:10 devananda: but goland is the other language where innovation is happening amount OUR developers already. right now. dramatically improving the operation of a core service 20:37:11 jbryce: in fact, trying to enable the same scale of development process we have done in Python for other languages will take away resources from what we're doing with pyhton today 20:37:45 jbryce: it improves the operational performance. it does not improve its alignment with the operation of the other openstack services 20:37:45 devananda: that’s assuming that making an inclusive decision here will not include anyone else who wants to pitch in on those things 20:37:46 So my read of the TC today is "the majority of us don't want to selectively add alternate languages, components in another language should be written as unofficial repositories and be depended on" -- is that correct ? 20:38:13 ttx: that is my position, for now 20:38:17 ttx: yes 20:38:24 mine as well 20:38:27 ttx: yes 20:38:29 I'll info it then 20:38:40 dhellmann: what could be done to help move your position? 20:38:57 mugsie : address the concerns I've described in that pastebin 20:39:13 #info the majority of us don't want to selectively add alternate languages, components in another language should be written as unofficial repositories and be depended on 20:39:26 mugsie I won't speak for dhellmann but addressing the concerns listed there would help show a willingness and attitude shift. 20:39:29 mugsie : and not just ticking the boxes, but demonstrating a difference in approach over the long term 20:39:46 annegent_, dhellmann ++ 20:39:47 still need to read that pastebin 20:39:52 dhellmann: and for designate - I would think we cover most if not all of these 20:40:09 what we call "in" vs "out" of openstack is feeling more and more artificial and meaningless ... this position makes that worse 20:40:32 mugsie : in the email thread where this came up someone showed significant performance improvements with what seemed like quite small changes to designate, so you haven't met the technical bar, in my mind 20:40:34 russellb: ++ 20:40:49 russellb: worse, but not unfixable in the future 20:41:04 dhellmann: they were not "quite small" 20:41:09 russellb : my position isn't set in stone. this is how I feel today, based on what I've seen 20:41:15 i.e. having a separate repo for the Go piece kinda makes sense to me 20:41:16 russellb: same with dhellmann 20:41:22 I could totally be convinced 20:41:22 mugsie : ok, my impression was that some were things like moving database queries out of tight loops 20:41:27 I just have not yet been convinced 20:41:30 i.e. one language per repo 20:41:40 that's sane practice anyway 20:41:44 mugsie : I have not tried to dig into the patches myself, so I may be completely misunderstanding 20:41:51 ttx: shall we drop rst and yaml and bahs from repos that include python? 20:42:00 notmyname: no, and you know that's not the case 20:42:00 ttx: yeah, that would make things much easier to swallow for me too 20:42:15 I work in some dual language repos, it makes things more difficult 20:42:31 dhellmann: there was never any patches. just numbers, and a direction to "go use caching" 20:42:44 notmyname: ask distro packagers (that's where my belief comes from) and they will tell you the same thing 20:42:52 which, for a component that can be global distributed is .... interesting 20:43:07 notmyname: that's a strawman. rst and yaml are not service languages, they're documentation and configuration. 20:43:36 russellb jbryce in and out, it's a false dichotomy that I won't buy into. I'm definitely willing to keep discussing and become convinced of a solution. 20:44:25 this entire discussion feels to me like we are letting day-to-day operational concerns define the vision and scope of openstack, which feels entirely backwards to me. IMO. 20:44:25 annegent_: +1 20:44:25 To be clear; an alternative not yet mentioned here would be for swift to voluntarily choose to not be an official openstack project anymore as a whole, correct? 20:44:26 annegent_: you just told them it’s out 20:44:47 re: in and out - I don't think this has created a false dichotomy at all. I think that we've said "we want to be able to install openstack via a combination of pip and distro packaging" 20:45:09 So the way forward that the majority recommends for Swift is, if I read right, to land the alternate object server in Go (hummingbird) into a specific repo and make it unofficial for the time being 20:45:15 many of our python projects have dependencies that are not written in python - but we consume them from stanard linux distro sources 20:45:32 where those components is developed, whether in openstack's repos or elsewhere, is irrelevant 20:45:33 JayF: it wasn't mentioned here but it was mentioned when this discussion started. I'm not advocating for that, though. 20:45:45 I have the feeling this is not the last time we discuss this 20:45:50 ttx: ++ 20:45:53 dougwig: ++ 20:45:56 ttx: but that's good, isn't it ? 20:46:09 Please don't forget the middle ground of gopy - https://github.com/go-python/gopy 20:46:16 * flaper87 has no problems with revisitng this again in the future 20:46:23 yes, it's good, just not sure how practical the proposed way forward is for Swift 20:46:35 mordred: i disagree that it’s irrelevant. but we may need to be on a beach to really have this discussion. = ) 20:46:52 ttx: It's a start, for sure. 20:46:55 jbryce: :) 20:47:07 We need to switch topic 20:47:10 jbryce: I think what I'm trying to say is that if people are hearing a weird false distinction, then we're communicating something wrong 20:47:19 the actual thing is quite clear and distinc to me 20:47:30 mugsie : you're right, I don't see actual patches in http://lists.openstack.org/pipermail/openstack-dev/2016-May/094568.html 20:47:33 jbryce: I'd be more than happy to use you as a sounding board to figure out who we're being unclear though 20:47:43 I just don't understand how this decision helps with all the arguments being made. In the end, swift will be forced to create another repo, where we you have swift developers in reviewing/writing code in both. It won' t really help with the 'community impact' anyway... 20:48:01 dhellmann: fwiw i asked - I was quite interested in them 20:48:16 tdasilva: I think the idea is taht it will prevent contagion and further fragmentation 20:48:25 will it? 20:48:25 tdasilva: we're focused on the total of openstack developers broadly, not the swift developers specifically. yes, this will suck for swift. sometimes things suck for one part of a larger whole 20:48:26 mugsie : good, and I expect there's a lot more to the story that I haven't heard 20:48:45 tdasilva: I'm not convinced, which is why I voted for some sort of compromise 20:49:06 is there a requirement that they maintain both the 'unofficial' go version and the 'official' python version? 20:49:17 The compromise I voted for is to start with this and evaluate the growth and impact as it comes 20:49:24 Also, what dhellmann said in the pastebin 20:49:24 gordc: no 20:49:25 mordred: it's not just that it sucks for swift, but we might be forcing other projects to follow the same route. 20:49:43 gordc: a lot of things in openstack depend on components written in other languages outside teh official projects 20:50:02 nothing says 'everything has to be python' 20:50:06 tdasilva: my desire would be that they learn from this experience and don't get themselves into such a rough place 20:50:17 mordred: ++ 20:50:23 ok, next topic 20:50:25 mordred: nice project you got there. shame if something were to happen to it 20:50:44 #topic Adds a docs: URL entry to projects.yaml 20:50:52 #link https://review.openstack.org/316396 20:50:55 thanks dhellmann for the patche 20:50:59 patching 20:51:10 this one is close but it's a rebase hell so I think we can quickly rebase / review / merge it in-meeting and be done 20:51:19 I had a question inline, it lgtm though 20:51:20 notmyname threats do not have a place here. 20:51:25 mtreinish ok 20:51:31 mtreinish I can look 20:51:41 it was just about projects that use developer/ for everything not just contribution docs 20:51:59 * flaper87 not a super fan of the missing `api` items but he's got no strong opinions there 20:52:12 mtreinish : that's a good point 20:52:30 mtreinish oh right. that's not what we're looking for _quite_ yet, mostly need to get a handle on the sizes. 20:52:43 it is a lot of projects 20:52:49 apologies, my last comment wasn't meant to be a threat at all. it didnt' translate in text 20:53:17 notmyname: I read it as joke fwiw 20:53:18 and linking to designate/developer has a lot of completly unreleated docs 20:53:18 such as, Oslo has 28 of the 80 contributor docs links 20:53:35 annegent_: size as in the number of things that have things up on docs.o.o/developer? 20:53:52 annegent_: given how difficult it is to merge things without triggering a merge conflict, I'd rather approve it now if we can 20:54:09 ttx: ++ 20:54:11 should this not link to the actual contributor docs? 20:54:13 mtreinish mugsie yeah, basically a content audit when there's 80 projects, what percentage are developer-centric? Turns out quite a lot on a page basis. 20:54:19 ttx: +1 20:54:22 * dims just finished reading the pastebin 20:54:22 ttx: I was fine with landing it as is, since it helps. I was just worried about the messaging around contributor (or whatever it was) 20:54:24 ttx yay yes 20:54:24 ttx: ++ 20:54:28 but we can fix that in a followup 20:54:34 ok, let's merge it now then, please pile on +1s 20:54:36 mtreinish yes, I do want to address that eventually... 20:54:38 mugsie : with this patch in place, I think annegent_ could ask teams to "fix" their links either in this repo, or by getting publishing working, or both 20:55:04 mugsie also I think it might help us think more about "frameworks" for docs rather than "write the docs" 20:55:14 dhellmann: annegent_ ack 20:55:23 annegent_: you read my mind :) 20:55:33 :) check! 20:56:01 dhellmann: did you mean to -1 the patch? There wasn't a reason on it 20:56:15 mtreinish : no, I can't remember how to use gerrit 20:56:19 heh 20:56:44 dhellmann: heh, that's what I figure it was :) 20:57:03 mtreinish : thanks for pointing that out :-) 20:57:07 ok, merging now 20:57:24 hopefully 20:57:43 #topic Open discussion 20:57:52 I'll miss next week meeting again -- flaper87 still interested in replacing me ? 20:57:52 thanks all, whew! 20:58:05 ttx: yup, I'll be around 20:58:17 annegent_ ++ 20:58:25 dhellmann : will you be posting that pastebin somewhere? Mailing list? gerrit comment? 20:58:30 I would appreciate some more feedback on the "goals" process proposal: https://review.openstack.org/#/c/349068/ 20:58:34 Anything else, anyone ? 20:58:46 #link https://review.openstack.org/#/c/342069/ 20:58:48 dhellmann: I was a bit surprised at the initial reaction on it... A lot of people seemed to conflate defining a few release themes into some intolerable intrusion in project design territory 20:58:49 dims : I hadn't planned to post it anywhere other than these meeting logs 20:58:53 round-table discussions for meetbot 20:58:57 needs some love 20:59:00 * flaper87 will ping infra folks 20:59:02 mordred: https://review.openstack.org/#/c/342069/ 20:59:04 :P 20:59:06 dhellmann : the content may get lost :( 20:59:08 ttx: I was less surprised by that than the concern about being kicked out immediately 20:59:09 flaper87: cool patch :) 20:59:14 russellb: thanks :D 20:59:20 dims : ok, I'll post it as a comment on your patch 20:59:26 thanks dhellmann ! 20:59:32 * flaper87 will add more to it as soon as the first version lands 21:00:12 thanks ttx 21:00:16 dhellmann, yes, surprising reactions. 21:00:34 ok, end of meeting, thanks everyone 21:00:37 bye, all 21:00:41 #endmeeting