20:01:08 #startmeeting tc 20:01:09 Meeting started Tue Jun 7 20:01:08 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:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:12 The meeting name has been set to 'tc' 20:01:16 o/ 20:01:22 o/ 20:01:24 alright... 20:01:30 Our agenda for today is: 20:01:35 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:42 #topic Call out GPL style licenses in testing/validation. 20:01:43 * Rockyg is petting a sweet cat that slinked in through the back 20:01:50 #link https://review.openstack.org/293140 20:02:01 Feels like everyone is in agreement here, so unless someone yells, I'll just approve this one 20:02:36 no yelling 20:02:47 approved then 20:02:56 #topic Remove Cue project team 20:03:03 #link https://review.openstack.org/324412 20:03:20 This one is about delivering on a promise some of us made of cleaning up the tent when a project just doesn't deliver on the expectations 20:03:32 Especially when a project does not process reviews anymore, or doesn't release anymore, or doesn't addess vulnerabilities anymore, or doesn't participate to events anymore, or doesn't hold meetings / discuss on ML anymore 20:03:53 Cue is a bit of a low-hanging fruit there, since they don't really have recent activity, missed the Mitaka release, missed the Austin Design Summit, and no recent meeting or ML discussion 20:04:12 ttx: I'm just curious is there an activity requirement for projects written down anywhere? 20:04:20 So I personally think they fell below the bar of activity that is expected of official OpenStack projects 20:04:20 mtreinish: no 20:04:22 I'm glad to see us taking these one at a time 20:04:23 case by case 20:04:33 mtreinish: actually there is 20:04:44 has anyone pinged vipul about it? 20:04:46 the release model tags specify release activity 20:04:53 but there is no metric, we are just asking that a project is active before we can vet it 20:04:53 mordred: I pinged min 20:04:54 ttx: yeah I was going to ask the same, is there a list or measure? 20:05:00 (the new ptl) 20:05:19 o/ 20:05:22 mugsie: ah - cool. 20:05:26 min was CCed on the review 20:05:38 ttx: it'd be nice if we had something we could point to in the commit msg 20:05:47 I think it's a case of a single-vendor project where the single vendor lost most of its interest 20:06:06 ttx: Sounds about right 20:06:13 because from my pov not every project is going to be super active all the time 20:06:14 ttx ++ and a highlight of the dangers of low diversity 20:06:23 diversity:danger 20:06:31 ttx: but in this case I agree with the single vendor losing interest 20:06:39 I'm thinking more for the future 20:06:41 mtreinish: missing releases is pretty bad 20:06:47 I think we have good input since Min answered, but did wonder about "who's next" 20:06:50 mtreinish: missing the release, the summit, the IRC meetings and no ML discussion is pretty much clear cut to me 20:07:01 yeh, it seems pretty straight forward 20:07:12 I mean, they can totally be back if they pick it up 20:07:13 ttx: Seems about right to me too 20:07:31 annegentle: not our problem of who is next. it's retired and someone can revive. 20:07:38 but fact is, they have not the level of activity that is expected of openstack projects at this point 20:07:46 thingee : we very well may end up with oslo libraries stable enough to not need a release in a given cycle, so it's not out of the question 20:07:50 Making it easier for projects to come in should also make it easier for them to go out 20:08:03 dhellmann: yes, in that case it's more of a combination of things 20:08:04 edleafe: ++ 20:08:11 the project also happens to be not mature 20:08:12 edleafe: ++ 20:08:19 edleafe: exactly 20:08:20 edleafe: ++ 20:08:22 dhellmann: as it stands, cue is part of the release, and they failed at that. That's fine for future cases that maybe out of the process. 20:08:22 ttx: right, that's why I don't think we want too many hard-and-fast rules 20:08:24 dhellmann: but the whole oslo project isn't going to dry up 20:08:27 greasing the door goes both ways 20:08:32 dhellmann: agreed 20:08:40 ttx +1 20:08:41 dhellmann: stability is a good point, when we come to making the rules 20:08:47 thingee : sure, I support removing them, I was just pointing out that we can't make "you didn't release" a firm rule that automatically drops a project 20:08:48 dhellmann: ttx: ok so rules/lists/metrics won't really work 20:08:49 I also think there is a difference, because oslo libs in some levels are like subtrees in a lot of other projects 20:08:51 case by case then 20:09:12 another way to look at it: if they applied today for the big tent, would we feel that they measure up? 20:09:20 fortunately we've got 13 elected representative humans that have human judgement 20:09:24 sdague : ++ 20:09:31 annegentle: yes. My rule of thumb for the start is... having a tc member who cares enough to propose the removal 20:09:32 ++ sdague 20:09:34 sdague: yes! 20:09:41 dhellmann: I'm confused by your "we very well may end up..." ... makes it sounds like this is not happen, so it's not really relevant right now? 20:09:42 sdague: yes! 20:09:46 I think coming up with an algorithm instead of just "representative humans" is the wrong thing to do 20:10:01 It's not "you miss a release, you're out" 20:10:14 thingee : it is not sufficient for me to say that because a project did not release, they must be removed from openstack. I gave an example of where that would be OK. 20:10:24 dhellmann: that's not what we're saying 20:10:29 It's just one symptom amongst others 20:10:32 dhellmann: that is just one of the things 20:10:40 ttx: that's all I wanted to clarify. Because the commit msg could be read that way 20:10:46 ok. that was the one I caught as it went past 20:11:06 mtreinish: oh, yes, there is no rule we are following here 20:11:20 we are not talking about archiving. just remove from governance. so easy +1 for removal 20:11:50 yes, in this case the project appears extremely inactive, as demonstrated by the many points raised. as long as we're all clear that no one of those points is sufficient on its own, I'm happy. 20:12:02 dhellmann: it's all still human judgement 20:12:06 ok, good 20:12:09 agreed 20:12:09 I think that's our algorithm 20:12:12 a TC vote 20:12:20 just a pile of symptoms and a gut call 20:12:24 yes 20:12:39 That case was arguably easy 20:12:45 which is why I posted it first 20:12:47 dims: you can bring something out of archive. Just like you can bring something out of retirement. 20:12:58 ok, looks like we have majority there 20:13:02 ttx: can we swap the next two topics (before we swap) 20:13:06 thingee true 20:13:09 also, unlike int the beforetime, we can take a project out of openstack without having to rename its git repos 20:13:17 ttx: the url entry should be less contentous/take less time. 20:13:18 notmorgan: sure 20:13:38 notmorgan: ++ 20:13:52 yeah sounds good to swap 20:14:01 fungi : was thinking about http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project steps 20:14:21 ok, so, I'll approve it now 20:14:48 approved 20:15:06 #topic Adds a contributordocs: URL entry to projects.yaml 20:15:14 #link https://review.openstack.org/316396 20:15:24 This is still in progress work, Anne do you have all you need to make progress ? 20:15:29 as I said in the review, it's a draft. 20:15:29 i'm generally for this, needs a little cleanup though. 20:15:35 yes 20:15:38 but it's def. going the right way 20:15:41 One tag removal in there 20:15:44 notmorgan: ++ 20:15:47 mestery: yes nice catch 20:15:54 annegentle: nice work though! 20:15:59 I'd like to figure out how to deal with projects with multiple repos with docs? 20:16:08 annegentle: yeah, that's what I was just gonna ask 20:16:11 annegentle: make it a list? 20:16:13 would it be better to put a docs: line for each repo? 20:16:24 because things like qa and infra have lots of very different projects 20:16:26 annegentle: hm. probably per-repo 20:16:27 someone tell me YAML solutions here :) 20:16:29 annegentle : where are we going to render/use this info? 20:16:32 annegentle: haven't read the latest PS but, did you find a way to avoid adding the repos with `None` urls ? 20:16:33 annegentle : or per deliverable 20:16:36 annegentle, could it be as simple as a link to a page with that list of docs? is there value in having all the links in the infra project? 20:16:39 dhellmann: ++ 20:16:46 that said, I'm certainly in favor of this 20:16:58 dhellmann: yeah per deliverable would be my vote 20:17:02 flaper87: I think I can leave the line blank instead of None, but I sorta used None to indicate "I'd expect something here" 20:17:17 annegentle: you can, but None is fine as well. 20:17:22 i like the explicits 20:17:23 annegentle : does the yaml parser turn "None" into a None value? 20:17:24 +1 for adding None explicitly, its kinda nice 20:17:26 amrith: not sufficient if I want to expand beyond contributor docs 20:17:33 dhellmann: not sure, good question 20:17:39 * dims envisions a pypi like interface for all this info 20:17:42 dhellmann: it should. if not we should make sure we're passing the right thing in 20:17:46 annegentle : because I wouldn't want the rendering code to have a special case for that 20:18:12 annegentle, if that's the case should the link be at the project level or the release level? 20:18:12 dhellmann: I'm nearly sure that it does 20:18:20 i think "null" is correct 20:18:23 not "none" 20:18:25 is there a way to say docs: and then what type? in YAML? 20:18:28 http://yaml.org/type/null.html 20:18:29 notmorgan: yeh, that might be 20:18:35 notmorgan: good point 20:18:36 sdague : possibly, but ... what notmorgan said 20:18:48 amrith: you might be onto something there 20:18:54 we can deal with that when we update the rendering code 20:18:54 annegentle: cool 20:18:57 amrith: release level perhaps 20:19:17 annegentle, maybe both? 20:19:22 annegentle: ok, so you will iterate on the review 20:19:25 ok I probably have enough to do another passthrough... for more reviews 20:19:28 yeah 20:19:30 annegentle: :) 20:19:33 thanks 20:19:34 annegentle: sounds good 20:19:34 thx annegentle 20:19:44 notmorgan: heh, I like the definition there, "devoid of value" 20:19:49 mtreinish: hehe 20:19:50 just wanted to make sure you had all you needed to make progress 20:19:58 next topic... 20:20:04 #topic Add golang as an approved language 20:20:04 like the review of my book, "this book fills a much needed void". 20:20:06 * dims dreads 20:20:08 * notmorgan braces for impact. 20:20:11 #link https://review.openstack.org/312267 20:20:20 OK, so I'll say this upfront, I dislike all the options we are given here 20:20:24 * edleafe gets the popcorn 20:20:32 Like Monty I tend to lose sleep over them over the past week 20:20:32 * notmorgan steals edleafe's popcorn 20:20:38 ttx: I think that's one thing we can all agree on. 20:20:43 ++ 20:20:43 Like there must be a solution that is perfect but I can't find it 20:20:43 ttx : yep, don't like it at all 20:20:52 I'll be honest, I feel backed in a corner. 20:20:58 Most TC members voiced their position on this one, I'll try to summarize 20:21:17 so fwiw, i've changed my view somewhat. 20:21:24 Flavio raised that opening the floodgates to another language is not the right call at this time for OpenStack 20:21:34 ttx: any chance this can be tabled until the TC tackles defining openstack? 20:21:35 o/ 20:21:39 As we are still struggling with driving more consistency and share more things between components of OpenStack 20:21:40 Timing, urgency, emotional ties... rather than data-driven. 20:21:44 dougwig: we kind of already did 20:21:52 a long time ago 20:21:57 dougwig: i would prefer to not take that on first if we're revisiting 20:22:01 * Rockyg hands edleafe a pot of hot butter 20:22:06 And I tend to I agree with Flavio -- I'm still very much supporting the 2011 view that OpenStack is a thing, rather than a loose collection of things 20:22:09 dougwig: this is about language first, scope is a separate convo 20:22:13 Rockyg: mmmmmm 20:22:15 if it is being revisited 20:22:23 But we are struggling to share more between projects, and I fear that adding Go would put the final nail in that coffin 20:22:35 mestery advocated that we should just let the projects use the best tools. 20:22:53 However I think Flavio's option is still giving projects enough choices, including letting projects use dependencies written in other languages, maybe he can develop that in a minute 20:23:05 dims said the TC should vet which projects did enough due diligence to get to use Go and which didn't 20:23:12 The alternative is to say they are not openstack if they use a language like Go I guess 20:23:14 which on the surface sounds like a nice compromise option 20:23:21 ttx : cross-project with guidance from TC 20:23:22 yeah, I'm really worried about the community impact this will have and I lean towards the 2011 decision we made. More importantly, I'm in favor of taking a smaller step this time (or no step at all) and give us some extra time to process the big tent change 20:23:28 But I really don't want that. I prefer to say "use a dependency" than be in the business of granting exceptions and telling others "no you're not tall enough to use Go" 20:23:48 mordred was very eloquent and I wouldn't dare summarize his views, maybe he can 20:23:49 ttx ack 20:23:59 ttx: no chance - that took me a long time to write 20:23:59 mestery: not necessarily, some projects can use a dependency model as the one proposed 2 weeks ago but some projects won't be able to do that and, admitedly, the project might need to make other decisions there 20:24:00 yeah, I can't imagine how we could effectively police the "appropriate" use 20:24:03 i am very very very very very very very against the TC saying "you can use go" individually 20:24:06 mordred: lol 20:24:11 dhellmann: +1 20:24:13 the TC has already supported other languages than python for valid technical reasons. and it seems everyone agrees with the technical justifications that have been given 20:24:15 ttx: I hate both choices, I just think one is a little less bad than the other 20:24:16 notmorgan: that we agree on 20:24:30 notmorgan: yup, not the plan 20:24:32 mordred: it's also easier to revisit, although I'd hate that too 20:24:37 * notmorgan summarizes mordred's email as "read the email for context" 20:24:40 flaper87: Some not all, thus my comment was relevant :) 20:24:41 notmorgan: ++ 20:24:42 Any others I missed ? 20:24:44 and we have in the past just let other languages slip in, and said nothing 20:24:47 I'd still like to see an attempt to use gopy to create an extension for the "slow part" so that the majority of the code can remain in Python 20:24:51 I think thingee is also on flaper87 option 20:24:52 mugsie: yup 20:24:54 mugsie: What? Blasphemy 20:25:04 * ttx ctaches up with recent reviews 20:25:06 mugsie: that was for mestery 20:25:12 lol :) 20:25:21 dhellmann : cross-project spec and debate at cross project meeting 20:25:21 flaper87: tab+m? 20:25:27 edleafe: all we've talked about now with swift specifically is a small part of the whole. we're not planning on rewriting everything in go 20:25:34 mugsie: guilty as charged 20:25:44 as long as we clearly say this is a big tent issue (go is not part of the tent), but (as long as infra doesn't raise a flag, and they havent), you can use our CI. 20:25:50 I like dtroyer's comment, it was spot on I think, and aligns with what dougwig mentioned too. 20:26:01 notmyname: that was more for Designate's concerns 20:26:02 i'm fine with it at this point, regardless of the direction taken. 20:26:06 yes, I think if the TC provides the option for projects to have an outside requirement based on go that's not part of the big tent, that would be fine. 20:26:16 mestery: then propose some removes if that is your primary concern 20:26:16 * notmorgan feels that a decision needs to be made today fwiw on this. 20:26:17 mugsie made good points on more fragemntation at specific project level vs. more fragmentation at openstack-level 20:26:20 thingee: ++ 20:26:22 thingee: and that as the add on point 20:26:32 notmorgan: +! on making the decision today 20:26:34 thingee : we don't currently have any formal restrictions about the language of third-party dependencies, do we? 20:26:35 sdague: Fair point 20:26:36 thingee : i'd like people to do their work here, not go elsewhere.. 20:26:44 the timing is what's troubling. Why didn't you come to the TC over a year ago to map out a plan notmyname ? Why are we in this position of a black-and-white decision? 20:26:45 does "not in the tent" mean that it's not in the openstack/* namespace at all? 20:26:51 dhellmann: nope 20:26:59 notmyname: nope 20:27:00 notmyname: the openstack/ namespace does not convey meaning 20:27:03 notmyname: no, just not in governance 20:27:12 thingee: that sounds like we're saying "if you develop your libraries elsewhere, you can use what ever language you want, and you can use them in openstack projects" 20:27:16 I also would ask, we are talking about devs who are cross -virtical project devs. - did we ever really have that many? (aprart from the period when stuuff was being brought out of nova) 20:27:21 notmyname: absolutely still possible to be in openstack/* namespace if they want to be :) 20:27:27 devananda : as long as you can pip-install them 20:27:29 dims: no one said to go elsewhere. you're still part of the community. it's the project's choice if they can't work with the option given 20:27:32 it is up to the project to make that choice. 20:27:33 notmorgan: is it? 20:27:37 dhellmann: or apt/yum 20:27:40 mordred: as much as I wish that were true, it is not 20:27:41 dhellmann: I can't "pip install mysql" - but we depend on mysql 20:27:47 mordred : or import from python, I guess I should say 20:27:49 mordred: right. that's better 20:27:50 mugsie: it is not the number it is the workload 20:27:53 devananda : mysql is not a lib 20:27:55 dtroyer: it may imply meaning to people, but it does not convey chosen meaning 20:28:01 mugsie: it is. infra has said they are willing to help make go part of the deal, like java can be, like javascript can be 20:28:04 mugsie: and those that do cross project have had an increaased workload 20:28:08 mysql is also not part of OpenStack 20:28:09 mordred: +1 20:28:20 anteaya: the point raised in the review was loack of cross-virtical-project developers 20:28:26 right 20:28:37 thingee : ttx : do we let code be in openstack/ git and use CI but just not in governance? 20:28:38 "not in the tent" just means "not under the TC rule" 20:28:41 mugsie: so the code can use opoenstack infra and be in openstack/* namespace, just not be in governance as an official openstack deliverable (it can be a dep like mysql is) 20:28:44 which is kind of what you want here 20:28:46 and the ones that are currently active have an increased workload 20:28:48 dims: yes. we have tons of things like that 20:28:50 dims: yes 20:28:55 whew ok 20:29:09 notmorgan: yeah - I knew that, but the issue around community costs is still going to happen then 20:29:27 dims: projects not part of the governance can already do that 20:29:39 having lots of things that are not OpenStack™ in /openstack is bound to cause external folk a ton of confusion 20:29:40 and some actually do already, IIRC 20:29:40 projects can continue to use openstack infrastructure and prove us wrong 20:29:45 mugsie: somewhat. it doesn't convey ATC, doesn't convey other benefits, doesn't convey VMT coverage, etc 20:29:48 what you're asking is that the swift contributors, in order to move forward with the best technical solution, will work in 2 separate repos? one under the TC and one not, where one is dependent on the other 20:29:49 s/a ton of/increasaed 20:29:53 and if the workload decreased to a managable amount we might get more folks doing cross project work 20:30:03 thingee : that softens the blow 20:30:12 cdent: it already is 20:30:21 notmorgan: ah, thanks for the clarification. would it be correct to restate that as "develop it using shared openstack resources, but not under openstack governance" ? 20:30:26 right on the dependency... I don't understand any technical reason not to keep having the separate golang solution for object portion? What changed notmyname other than ttx's request? 20:30:28 not sure what practical difference it makes to infra/docs etc 20:30:30 cdent: I disagree, we have things not part of openstack that are dependencies for certain use cases. 20:30:38 devananda: yes, better phrasing 20:30:59 thingee: I'm just reporting what people tell me 20:31:00 notmorgan: maybe I'm being obtuse, but what's the practical difference, then? 20:31:05 notmyname: i would almost argue that should be the case in either case. 20:31:05 annegentle: that is what we're planning on. having a golang object server (and a few supporting daemons). but there's not a dividing line between that and the rest of the project 20:31:24 cdent: I'm just reporting what is happening today :) - I mean libvirt is fine for example 20:31:36 cdent: that was recognized when we got rid of stackforge 20:31:41 notmyname: the trick is how to allow you to do that without breaking the rest of openstack with crazy Golang rewrites 20:31:49 notmyname : we would also need to decide how that dependency is consumed. I'm not sure devstack would want to install it from source, for example. Maybe? 20:32:04 devananda: it's a resource allocation thing, horizontal teams are not required to be part of it, and those resources are very constrained. 20:32:11 devananda: and a marketing thing. 20:32:12 dhellmann: ++ 20:32:19 it's like going to any other project and picking some files from some subdirectory and asking those to be developed in a separate repo now 20:32:23 notmyname: is there a technical problem with the dividing line? (really trying to understand, this is not a judging stance) 20:32:28 so, as a straw man, we could have a repo that docs the usage, and how to install a repo in openstack/ , and for features requires work in both repos, but the 2nd repo is not part of openstack 20:32:34 dhellmann: notmyname but that's something we can work together on with the infra team and whatnot if needed 20:32:43 what is the difference then 20:32:44 dhellmann : i dont know how doing this way in any way reduces burden on cross project teams... 20:32:55 annegentle: yes. I went into this in great detail in an email to tts and flaper87, but that's not currently a public document 20:32:57 annegentle: yes there is... notmyname explained it to me quite well. the way swift is designed makes it hard to split it along dependency lines 20:32:59 ttx: I find your use of the word "breaking" there interesting, why does re-writing things in golang inherently break things? or do you mean break openstack into two communities, between the go bits and the python bits 20:33:02 notmyname: ok 20:33:12 which is why it's not a nideal solution at all 20:33:14 annegentle: notmyname: happy to share the contents of that email 20:33:14 cdent: agreed the current state of /openstack is confusing, points to the deeper questions we still need to answer here 20:33:17 jroll: community 20:33:25 flaper87: I would totally support that 20:33:29 mordred: noted, the wording threw me 20:33:33 flaper87: notmyname: thanks that will help me understand 20:33:47 annegentle: notmyname: coolio, I'll probably just put everything on an etherpad 20:33:49 notmorgan: I am struggling to see how the distiction of whether a golang-based project falls under TC guidance has any bearing on cross-project teams (aside from the TC) 20:33:57 flaper87: annegentle: I can put it on the ML after the meeting 20:34:00 devananda : me too 20:34:01 devananda: docs team, VMT, etc 20:34:09 annegentle: it's a problem that is linked to the very integrated design in swift, other openstack projects are less likely to have the same problem 20:34:11 devananda++ 20:34:12 notmorgan: docs, VMT, etc, already don't have to care about new projets 20:34:16 ^ 20:34:18 notmorgan: so why would they care about this one? 20:34:19 I basically still sense that the problem is complex, the solution proposed is too simplified, so we all can't agree. 20:34:20 devananda: dims we spend a significant amount of time hand holding every little piece of dev 20:34:26 devananda: but the non-governance repos can't ask for these resources 20:34:31 devananda : not true. They don't have to do the work for them, but they have to support them with tooling and guidance. 20:34:35 annegentle: yes 20:34:55 devananda: in an official capacity that is 20:35:02 clarkb : saying, you can create new repos with go code and use CI/infra etc..does not reduce that burden 20:35:09 having to go to teams and re-iterate what took place in a different meeting or summit session that they didn't know about because they were doing their own work 20:35:13 dhellmann: I see. so the removal of the expectation that horizontal teams do (or do not) have to provide guidance to go-lang projects -- is that the sticking point? 20:35:16 devananda : that resulted in "the install guide" being renamed and repurposed, for example, to make space for other guides 20:35:21 dims: yes it does I dont have to debug your tests when they fail 20:35:28 there is a lot of repeating of events that goes along with cross project work 20:35:38 devananda: dhellmann: well, you end up getting a parallel set of tooling for all the go folks I guess? regardless of who does it 20:35:42 or teach you how to use sphinx etc 20:35:51 clarkb: even for some big tent projects - they dont get that 20:35:51 clarkb : interesting distinction 20:35:53 devananda: that is part of the deal. also marketing from the foundation and ATC etc conveyance would be excluded 20:35:54 clarkb: adding a dependency on another language, regardless of whether horizontal teams support that language, or whether the TC has oversight, still results in "me needing to debug it when it fails and affects my gate" 20:35:59 mugsie: they totally so... 20:36:09 I spend a large chunj of my time debugging your code 20:36:12 clarkb: so adding golang _at all_ carries that shared debugging burden 20:36:16 johnthetubaguy : possibly. expectations for something likes i18n might be lower if the project isn't official. 20:36:22 dhellmann: ++ 20:36:26 devananda: true 20:36:28 oops 20:36:30 regardless of TC oversight of golang-based projects 20:36:30 clarkb : so we'll let folks use other languages instead of swift in new git repos? 20:36:32 dhellmann: true 20:36:34 devananda: infra costs are mostly similar. It just makes it a lot harder to introduce new organizations to "openstack development", for example 20:36:43 or drive any sort of cross-project initiative 20:36:48 oops golang 20:36:59 ttx: ok, thanks. that is what I envision, but not what notmorgan was claiming above 20:37:03 why not have two separate object storage projects that implement the object storage API defined by the object storage program? 20:37:12 dims: we already do... java, Go, php, even objective C I tink 20:37:14 devananda : that's a good point. and projects may choose not to depend on unstable unofficial projects for that reason. 20:37:26 scotticus: that's not what was proposed, nor what we're discussing 20:37:29 notmorgan: from a practical perspective i would have a hard time feeling ok with excluding talking about something that is a better user experience developed by the same team that develops the rest of the project…. 20:37:59 * dhellmann has to drop off 20:38:03 jbryce: there is a difference from the standpoint of "this is an openstack project" and "this is a dependency such as mysql" 20:38:12 jbryce: my words are insufficient to cover the fidelity there 20:38:32 jbryce: it may be the best experience to do this with this dependency 20:38:33 notmorgan: jbryce: but in this case, you're talking about a required dependency that's developed by the same group of people 20:38:51 notmyname: * and on the same shared infrastructure :) 20:38:57 notmyname: i'm going to go out and say RDBMS is required. 20:39:03 we are already building a solution out of things that are developed in openstack, or developed in openstack infra but by non-TC-driven teams, and stuff that is developed outside. The question here is where do we draw the line 20:39:05 notmyname: and in most cases that is mysql 20:39:29 ttx: or developed by openstack people out side openstack and inside openstack that depend on openstack 20:39:39 that came out messy but you get my point 20:39:45 we typically do not depend on external _source_ repositories. we depend on released binaries of things 20:39:46 * flaper87 hopes 20:39:51 (dont read my comments as anti new lang I enjoy the challenges, but generqlly think that alot of the cross project work is taken for granted when we complwtwly fix the random lang rwlated test thing that broke your tests and ypu didnt notice because we fixed) 20:39:57 so we do not install mysql from source to install openstack 20:39:58 ttx: to me the line is drawn based on priorities, and right now I don't want to prioritize in this language-contributor-centric way. 20:40:02 clarkb :) no worries 20:40:03 we apt-get/yum install mysql 20:40:06 but in this case it's that you've got one group of people working on one thing, but forced to develop it in two separate repos 20:40:07 it's a dependency 20:40:26 clarkb: yes, that. 20:40:36 clarkb: <3 20:40:39 notmyname: yes, that is why I don't like this solution. I just hate it less than the other option 20:40:41 clarkb: and thank you :) 20:40:42 annegentle: that pretty much summarizes my comment and concern. 20:41:13 ttx: the other option being golang is ok? (which everyone has agreed is probably the right answer, technically) 20:41:46 notmyname: technical merits aren't the only (or most important) thing 20:42:00 ttx: if i'm following, this will force openstack projects that want to develop some compoent(s) in golang to build, test, and publish those component(s) independently,so that they can be installed via package managers 20:42:00 notmyname: the other option being to say that rewriting things in Go is ok across the board, and struggle to drive cross-project goals or specs incrementally more 20:42:03 ttx : are we back where we are or do we need a resolution to say - "You can be in big tent only if the project is written in python"? 20:42:09 the technical merits is not what we're weighting more here, fwiw 20:42:18 we are essentially saying that here 20:42:30 so it's about project-centric pain vs. cross-project pain. You can actually see that in the vote spread 20:42:39 dims: you already don't need that. 20:42:41 dims: or rather, you really need to demonstrate why you *can't* write it in Python 20:42:41 dims: i feel like i have a solution for that :P 20:42:42 in a pre-big-tent world, the drawing of the lines would seem more rational to me, but in a post-big-tent world where we’ve already created a lot of confusion externally, this seems like an arbitrary place to deny an official project team’s consensus request, discussed over 3 design summits, on mailing lists, back by data… 20:42:44 dims: I think that would probably be the result of this discussion ... a resolution of some sort 20:42:46 or proposal. 20:42:58 annegentle : we don't say it explicitly, we should now that we have a decision here 20:43:02 ttx: if that's a correct summary, I would restate it as "non-python projects must be developed and released completely independently, and consumed by python projects only in their binary / released / distro'd forms" 20:43:02 dims: it's that this proposal is written too black-and-white. 20:43:06 thingee ++ 20:43:27 devananda: I believe you stated that very clearly 20:43:39 devananda: ++ 20:43:40 annegentle : don't know how else it could have been written :( 20:43:46 annegentle: how so? what shoudl change? 20:43:57 big tent was a much bigger move in terms of cross-project impact and we sort of ran headlong into that one. and i thought that was about a shift of “what is openstack” to “who is openstack” 20:44:07 dims: notmyname: More like the considerations upfront than the "contributors are in pain let's alleviate that" 20:44:10 jbryce: ++ 20:44:25 jbryce: yes, and "who is openstack" is defined by the practices that we share 20:44:32 ttx: ++ 20:44:37 notmyname: though what I also would dive into is what was the order of javascript additions? 20:44:44 annegentle : don't know if it would have changed the outcome 20:44:47 blunt question: we've talked a lot about the community impact here; has anyone considered the impact if swift decides to no longer be part of openstack? 20:44:51 and I feel like this is extending it beyond our capacity to absorb it 20:44:59 notmyname: it's possible my history order is incorrect 20:44:59 ttx: ++ 20:45:44 I don't like yes, I don't like no, and I don't like stalling. Someone help me 20:45:58 if openstack is wanting to be a series of control planes, shouldn't it just be a collection of API contracts/definitions? 20:46:13 ttx: it doesn't help, but I am in the same camp right now 20:46:24 scotticus: no 20:46:31 it's never been that scotticus 20:46:31 scotticus: that was decided a very long time ago 20:46:36 scotticus: no, that was decided a long time ago 20:46:43 edleafe: jinx 20:46:43 mordred: jinx 20:46:44 everyone abstain? (looking at @notmorgan) 20:46:45 scotticus: tbh, I believe that's quite a loaded question that's not going to help with this discussion but no is the answer 20:46:46 hahaha 20:47:06 dims: no i don't think adding it is going to work, and i cannot -1 rollcall the addition 20:47:06 * flaper87 hands a cookie to edleafe and mordred 20:47:07 ttx: go to what the data says. we've got data points from swift and definite interest from other projects as well 20:47:14 dims: i agree strongly with both notmyname and mordred 20:47:23 i definitely don’t think this is an easy one at all. i know that several have said they don’t like the idea of opening up alternate languages on a case-by-case basis through a tc approval process, but in the situation where there isn’t a clear consensus for one side, maybe that is the right way to start 20:47:24 dims: stalling it would be an option, but I don't feel like it's much better for notmyname than saying no 20:47:41 dims: and since i cannot and CANNOT make a case here right now, i will support the decision made. 20:47:42 agree 20:47:43 the swift team has set a pretty high bar for making that justification 20:47:48 If the desire is to be able to include add'l languages in the future - why not establish a team to go off and create a proposal for the TC to review/approve by some point in time? 20:47:56 jbryce: exactly. Demonstrate why you need Go or anything else 20:47:59 I think the TC getting a bit more involved in actually guiding projects is not a bad thing at all 20:47:59 literally over more than a year of time, testing, data gathering 20:48:03 edleafe: to whom ? 20:48:08 dtroyer: ++ 20:48:13 ttx: to the TC 20:48:19 dtroyer ++ 20:48:27 ttx: that is a technical decision, no? 20:48:28 edleafe: has swift not done that sufficiently yet? 20:48:28 notmyname: what would the impact be if the golang parts of swift were released independently and consumed by the rest of swift as system libraries (eg, apt-get install my-faster-swfit-lib) ? 20:48:36 dtroyer ... ++ 20:48:39 and if we can’t feel good about a blanket deicision, maybe we are just not at a point to be able to make the blanket decision and we need to use the tc algorithm like sdague said 20:48:42 devananda: apparently there's a document about that 20:48:46 notmyname: For swift, yes. For Designate, no 20:48:53 annegentle: oh? 20:48:56 edleafe: I really fear we'll be back into granting exceptions, and judging projects technical analysis 20:48:56 ttx : we can let folks add proposals to cross-project specs and talk about it there and vote on the spec and let some amount of vetting happen 20:49:09 devananda: I asked something similar and flaper87 and notmyname can send 20:49:12 will give a say to everyone in the process on a specific projects plans 20:49:16 like swift is pretty clear-cut, I totally get why they need go. What about designate ? 20:49:17 devananda: it would be very disruptive for swift contributors. it's a very silly and arbitrary project division. we would likely do our best to keep them as unified as possible 20:49:21 ttx: maybe that how we don't stall and don't decide right now? 20:49:33 notmyname: hence the dislike of making all Go (or anything else) accepted by default 20:49:43 notmyname: ok, thanks 20:50:07 i agree that TC should not be the police. can we use cross project to do that? 20:50:17 * jlvillal wonders if the 'repo' tool would help with multiple project development 20:50:17 dims: doubtful. 20:50:19 So... one option would be to give Swift an exception and let them use Go. That is pretty safe. But that makes them special again 20:50:26 dims: noone likes to be the police 20:50:26 ttx: yes, but I don't see any way out of that. Unless we're willing to trade community for a bunch of loosely-associated tribes 20:50:28 honestly, my biggest challenge, if the TC says "split", as PTL would be to convince swift contributors to not ragequit and find something else to do 20:50:34 dims: fwiw, I'd prefer the TC to do that in this case 20:50:43 notmyname: fair data point 20:50:52 no, I'm not for special case. I'm really unhappy with the previous special cases. 20:50:53 flaper87: ++ 20:50:58 ttx: I honestly would prefer to stay consistent in this case 20:51:03 so no special case 20:51:08 thingee: I've never asked for this to be a special case for swift :-) 20:51:36 that's all the ideas i had :) 20:51:37 i'm at the point that i think (don't hate me) a special case is the only thing i can vote for/against clearly 20:51:39 time check 20:51:50 I don't really understand how stalling is going to bring some magic answer to this. It's a difficult decision, but the TC has weighed in on the issue. I think both options suck, but I don't really understand the point of decisions being made if we're not going to go by them. 20:51:51 notmorgan: agree 20:51:58 thingee: ++ 20:52:05 stalling is not going to answer it 20:52:07 so in a years time, we will know the impact it has had on swift 20:52:08 thingee: +1 20:52:08 So I'm open for someone (dims) to propose a mechanism by which we would be able to vet projects individually 20:52:16 thingee: ++ please do something, and then follow though on it 20:52:18 bascially a stall here is a -1 imo 20:52:20 thingee: ++ 20:52:28 ttx : very cool. i am open to that 20:52:30 its possible swift will build a group of folks that work well in both go and python 20:52:37 or they might decide to move everything to go 20:52:38 dims: I'd love to help 20:52:40 johnthetubaguy: it's already been in discussion for a long time, and the impact is becoming clear to that project 20:52:48 but the current resolution can' tpass at this stage, unless a few people who voted -1 decide to change their vote 20:52:50 edleafe : ack 20:52:53 dims: ttx until that happens, I think we should stick with what's been voted on 20:53:14 we have a majority to deny this as it stands 20:53:16 ttx: so i think the answer is no to golang. by the nature of the votes. 20:53:18 dims, I'm interested in that as well; am happy to help with that proposal. 20:53:25 amrith : ack 20:53:28 ok, so we stall because some member abstain and need more time? 20:53:28 all the things you're proposing as future things for swift is exactly what's happened in the feature branch. which seemed entirely ok with everyone. and now we want to merge some golang code to master and this is what it's turned in to 20:53:56 notmyname : i'll need your help as well 20:54:06 dims: me too 20:54:14 dims: with what now? I missed somethign it seems 20:54:29 notmyname : " So I'm open for someone (dims) to propose a mechanism by which we would be able to vet projects individually" 20:54:29 notmyname: basically special case with a clear set of guidelines for anyone wanting it in the future 20:54:41 notmyname: propose a mechanism for selective access to extra languages 20:54:41 notmyname: so it's "here is how you get approval for this" 20:55:13 ok 20:55:20 dims: I and other members have expressed we'd not like the TC to be part of that process. 20:55:23 if we assert that allowing go will break the community, and then allow a select few projects to use it, won't that still break the community? 20:55:23 does that imply that the TC is ok with swift's code repo having golang code? 20:55:27 * jroll devil's advocate 20:55:30 since it looks like we can't resolve ourselves to accept blank approval 20:55:32 ttx: so lets call it "no to golang in this proposal". 20:55:33 jroll: ++ 20:55:33 dims: to which others expressed the community should vet 20:55:36 jroll: ++ 20:55:36 thingee : yep, i mentioned that already 20:55:38 which I also don't think is productive 20:55:41 notmyname: revise not to "go or no go" but to a "here's what we expect from projects when they add a language" 20:55:55 fwiw, I'm on the 'allow' side of this line but don't get a vote 20:56:02 thingee: i think at least one other tc member said he would like to be 20:56:04 as far as notmorgan's objection earlier to the TC getting back into the busiess of special casing projects, I agree - TC shouldn't do that 20:56:05 jroll: small cracks are much better than chasms 20:56:14 annegentle : agree 20:56:28 jbryce: I'd hate to repeat pre big tent unproductive discussions. 20:56:29 edleafe: small cracks widen over time 20:56:30 edleafe: I disagree that it would be any worse allowing anyone to use go 20:56:35 If the TC won't take the role of making decisions about governance across the projects, then who should? 20:56:51 I thought that was a key part of the TC charter 20:56:53 edleafe: or any "larger of a crack", using your analogy 20:56:55 carolbarrett: the TC does make decisions across projects 20:56:59 I seem to be seeing a lot of contradictory things being said. let's special-case. specical-case is bad. no golang. but here's how any new language should be ok 20:57:09 jroll: as someone who maintains common infrastructure everyone has to use in the gate, it's always worse when people do things differently 20:57:09 ttx: so. 20:57:12 carolbarrett: but blessing exceptions to its own rules? that's not what the TC is about 20:57:13 if i am reading this: 20:57:16 notmorgan: I'm lost 20:57:23 1) No to golang, blanket is what i am hearing 20:57:28 please correct me if i am wrong 20:57:34 yes, I think that's fair 20:57:42 devananda: sounds like a cross-project governance decision to me... 20:57:42 sdague: right, so why is allowing select people to do something different better than allowing anyone? if nothing else, allowing anyone will make that special thing less special 20:57:43 that’s where the votes on the review sit currently, yes 20:57:47 2) dims, notmyname, etc will come up with a guideline to cover access for other languages 20:57:50 3 mins time check 20:58:03 something we can judge the projects by 20:58:07 jroll: I agree, I don't think it's better. And wouldn't really feel any different about it. 20:58:13 notmorgan: and there are some people who have expressed interest in that, some who have express dislike, and others who have not said anything 20:58:14 3) Swift is not being told no to "golang" 20:58:20 sdague: fair enough 20:58:24 mordred: i dis like it a lot 20:58:27 notmorgan: somehow, I'm afraid that guideline will endup in the TC voting on the same thing we're voting on right here 20:58:33 notmorgan: right. I'm just annotating 20:58:36 but I could be wrong, need to read it first 20:58:37 mordred: ++ 20:58:38 notmorgan: hmm, expand on 3 ? 20:58:51 well, i think this is going to end in the current language policy 20:58:56 3) swift is being asked to rpopose the way we vette projects - and they'd be the first in the line for it 20:58:57 notmorgan: like, 2 isn't "we've agreed it's a good idea" - more, 2) may be another avenue worth discussing pending details 20:59:02 because we are not really saying yes either ;/ 20:59:05 ttx: I feel like this meeting should use executive privilege and keep going for a few minutes to get to a conclusion 20:59:05 notmorgan: 3 seems to conflict with 1 20:59:09 use python, want something else go to the TC 20:59:11 not being told to "go away and split off" 20:59:16 explicitly 20:59:19 it was more of 2a. 20:59:21 not 3 20:59:29 notmorgan: yeah 20:59:29 that was what i read from this meeting. 20:59:30 notmyname: I'm fine with that yes 20:59:37 I think we need a few extra minutes 20:59:50 next meeting if any could move to another room 20:59:51 i was just summarizing what i saw in the meeting 21:00:02 although that makes me getting drunk to forget all this later away 21:00:13 notmorgan: sounds like a fair summary to me 21:00:19 ttx: I don't see a conflict in the ical schedule 21:00:23 ttx: I'm ahead of you on that ;) 21:00:31 * flaper87 acts normal 21:00:40 ttx: maybe we should all have a few drinks, and then continue :) 21:00:44 yeah, I think that is a good summary, and its not self-consistent really, hence the issue 21:00:44 we need to find a reasonable way to vet proposals and make aware of people the deeper issues behind choices 21:00:48 So, summary 21:01:08 So, something I'd like to be more clear about: What does swift gain by being in OpenStack? 21:01:18 I think 1 is the only thing that's clear - 2 and 3 are maybes as things to explore to mitigate the results of 1 21:01:51 since there are clearly people who are unhappy with 1 - and working to find ways to move forward are the next steps that we are likely to explore 21:01:53 mordred: right, I believe #2 should be very specific. Something projects would apply for and that defines the process to get a vet 21:01:53 cdent: i am going to say that is a convo outside the scope of this - please please do not bring that part back in here. Swift has decided they want to be part of openstack, i am willing to view that as face value worthy 21:01:55 We have a framework for accepting extra languages (and this proposal was made under it) that grant blanket access to extra languages 21:01:55 to me it sounds like people are generally uncomfortable with both of the blanket options currently on the table, but feel that it’s potentially more harmful to open the “flood gates” to an unlimited set of go proposals across all projects 21:02:02 * Rockyg hands mordrd a bottle of single malt 21:02:04 jbryce: yes 21:02:16 Rockyg: yo, don't forget me ! 21:02:19 jbryce: ++ 21:02:24 jbryce: +1 21:02:28 I think that there is a majority at the TC that is not comfortable with Go blanket access 21:02:30 jbryce: yes. 21:02:35 * Rockyg passes out glasses 21:02:35 heh heh ... Rockyg gives edleafe butter and mordred single malt :) 21:02:37 jbryce: more than that. When the next new popular language comes up, why say no to that one? And then the next? 21:02:46 There MAY be room for more selective access, although a lot of us hate what that may mean 21:02:57 * edleafe thinks Rockyg is typing in a pantry 21:03:01 * dims carries the burden 21:03:01 ttx: right. but it's possible that that is less bad to people generally 21:03:06 but that eeds some work, basically a new framework for us to accept language additions 21:03:13 * amrith carries dims 21:03:14 depending on what magic dims and notmyname write up 21:03:15 jbryce: additionally, some members of the TC do not want the TC to be in the positin of judging which projects are 'worthy' of using golang 21:03:20 mordred: yeah, maybe, devil is in the details 21:03:33 devananda: but that still may be the less worse option htere 21:03:40 ttx: right. I don't have a strong opinion on that yet, as I haven't spent much time mulling it, personally 21:03:42 at the same time do most people acknowledge that hummingbird provides a technical improvement for swift? 21:03:42 cdent: marketing events infra test docs automation debugging frameworks a community and more. but no commas ever. :) 21:03:49 devananda: which is too bad because I think that is its job… 21:04:00 jbryce: I do not think anyone disputes that 21:04:06 so as far as this patricular resolution is concerned, I think we need to deny it 21:04:07 jbryce: mordred ++ 21:04:17 jbryce: I think that's the point: swift demonstrated clearly why it was necessary 21:04:19 dtroyer: we were in that position before the big-tent .. it's not great 21:04:20 jbryce: that's not the heart of the belief set this change brings 21:04:23 jbryce: I'd agree to that. 21:04:23 ttx: and wait for what dims and others will work on 21:04:42 devananda: as implemented then, right. I think we're worse off now 21:04:50 which is why I want to find a way for them to use it without killing the cross-project efforts while doing it 21:04:51 jbryce: the vexxing part is balancing the tech and the non-tech results - since the two aren't directly comparable 21:04:52 dtroyer: constructively, I disagree 21:05:08 jbryce: if it was all one or all the other, I think this would be much easier to talk about and discuss and whatnot 21:05:30 honestly, i'm willing to special case swift here. provided they work with dims et al on a forward proposal. 21:05:33 * dhellmann returns 21:05:37 mordred: also +10000 21:05:38 dhellmann: welcome back! 21:05:39 and also the swift project team sees a separation of the hummingbird object server implementation from openstack swift bits as a difficult ongoing softward lifecycle model to follow? 21:05:50 jbryce: yes. absolutely 21:06:07 openstack/liberasurecode also provides a technical improvement for swift, but is consumed as an unofficial repo. it might help to outline how hummingbird is in a different situation 21:06:07 jbryce: yup, that was the feedback we got 21:06:08 jbryce: notmyname to me it's unclear why that separation is untenable 21:06:09 jbryce: and also results in local fragmentation 21:06:10 * mordred is now arrived in his trainstation - y'all enjoy, must AFK 21:06:11 devananda: Someone has to make decisions, it's a fact of life. The TC is elected to govern the projects. If a person isn't comfortable making decisions, then why would they want to be part of the TC? 21:06:21 mordred: yeah i get that part. as i said to ttx and thingee earlier i’m torn myself because of it 21:06:39 carolbarrett: it's not about making decisions or notmaking decisions 21:06:40 mordred: safe travels 21:06:52 fungi: yes I wondered that as well 21:07:09 fungi: that's an external project, just like mysql or anything else. but we wanted it to move to openstack/* because frankly lawyers let employees contribute there isntead of some random bitbucket repo 21:07:22 dhellmann: summary is we'll deny this one, and some people will work on a new framework that lets us get the technical benefits without most of the community drawbacks, by rating more selective access 21:07:28 fungi: and the original authors have about a hundred other thigns on their plate too 21:07:29 notmyname: but the swift community is contributing to it? 21:07:35 fungi: some 21:07:41 fungi: just like we do to eventlet 21:07:44 devananda: would be interested to have a follow-up conversation to better understand your viewpoint 21:07:48 are swift team members its primary contributors now? 21:07:52 carolbarrett: be happy to 21:08:01 s/rating/granting 21:08:02 fungi: hard to say. the move is recent 21:08:13 devananda: Thanks 21:08:33 timecheck again 21:08:42 ttx: that sounds like restarting this discussion and having it again with some different details 21:08:47 I don't think we'll get any further today 21:08:49 ttx: 8min over. we can continue for a few more. 21:08:59 for the record, I think rejecting this proposal is the wrong choice 21:09:57 noted 21:10:05 notmyname: recorded 21:10:10 (wanted that on the record so in 5 years when meeting logs are brought up again, it'll be there) ;-) 21:10:15 notmyname: hehe 21:10:16 notmyname: heh nice 21:10:19 notmyname: and maybe prove you right 21:10:21 :) 21:10:26 should add something as a comment that a different proposal will appearsoon 21:10:32 ttx: if we need to wait 5 years... i'm going to be sad. 21:10:44 ok, I'll comment on the review to call it, and close this meeting 21:10:52 unless anyonte has items for open discussion 21:10:57 yes, one final thing please 21:11:04 #topic Open discussion 21:11:08 notmyname: go for it 21:11:27 so fir now, it seems that the swift contribs will continue. and I'll work with dims. and this will be brought up again 21:11:46 notmyname: that is how i understand it. 21:11:47 no mandate from the TC that swift needs to split into differnet projects, one in and one out of openstack 21:11:51 (just a review request, if TC can approve https://review.openstack.org/#/c/323027/ -- it will help Puppet group to release Newton b1, thanks) 21:11:57 for the record, I'm really losing sleep over this. Sometimes I wish I cared less 21:12:15 notmyname: nothing of the sort 21:12:20 carolbarrett: short version is: judging the "value" or "worthiness" of a project (and the team of developers behind it) is detrimental to community building, and created a lot competition between projects and negative pressure on the TC 21:12:26 ttx: thanks for the summary, there was a lot of scrollback 21:12:33 notmyname : no change in status quo 21:12:39 notmyname: just no to the resolution as it stands 21:12:40 thanks for the explicit clarification 21:13:00 ttx: new topic: I would like to find a way to merge changes to the projects.yaml file that only affect release tags faster, because the week review delay is holding up some project releases. 21:13:02 notmyname, so, limbo still.... 21:13:03 carolbarrett: so the TC adopted more objective guidelines for "being one of us" rather than subjective judgements of "being good enough to be one of us" 21:13:07 Rockyg: yeah 21:13:35 devananda: if we have a set of criteria, then everyone in the community knows the rules... 21:13:35 EmilienM: proposal works for me btw. 21:13:39 ok, thanks everyone, we need to close it. 21:13:45 thanks ttx 21:13:46 thanks ttx 21:13:49 ttx: thank you 21:13:52 Now let's bring me that bottle of Absinth 21:13:54 thanks notmyname 21:14:00 carolbarrett: exactly. I think that's what this discussion has been, in part, about 21:14:02 #endmeeting