20:01:08 <ttx> #startmeeting tc
20:01:09 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:12 <openstack> The meeting name has been set to 'tc'
20:01:16 <mtreinish> o/
20:01:22 <johnthetubaguy> o/
20:01:24 <ttx> alright...
20:01:30 <ttx> Our agenda for today is:
20:01:35 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:42 <ttx> #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 <ttx> #link https://review.openstack.org/293140
20:02:01 <ttx> Feels like everyone is in agreement here, so unless someone yells, I'll just approve this one
20:02:36 <ttx> no yelling
20:02:47 <ttx> approved then
20:02:56 <ttx> #topic Remove Cue project team
20:03:03 <ttx> #link https://review.openstack.org/324412
20:03:20 <ttx> 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 <ttx> 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 <ttx> 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 <mtreinish> ttx: I'm just curious is there an activity requirement for projects written down anywhere?
20:04:20 <ttx> So I personally think they fell below the bar of activity that is expected of official OpenStack projects
20:04:20 <thingee> mtreinish: no
20:04:22 <dhellmann> I'm glad to see us taking these one at a time
20:04:23 <thingee> case by case
20:04:33 <ttx> mtreinish: actually there is
20:04:44 <mordred> has anyone pinged vipul about it?
20:04:46 <dhellmann> the release model tags specify release activity
20:04:53 <ttx> but there is no metric, we are just asking that a project is active before we can vet it
20:04:53 <mugsie> mordred: I pinged min
20:04:54 <annegentle> ttx: yeah I was going to ask the same, is there a list or measure?
20:05:00 <mugsie> (the new ptl)
20:05:19 <flaper87> o/
20:05:22 <mordred> mugsie: ah - cool.
20:05:26 <ttx> min was CCed on the review
20:05:38 <mtreinish> ttx: it'd be nice if we had something we could point to in the commit msg
20:05:47 <ttx> I think it's a case of a single-vendor project where the single vendor lost most of its interest
20:06:06 <mestery> ttx: Sounds about right
20:06:13 <mtreinish> because from my pov not every project is going to be super active all the time
20:06:14 <dtroyer> ttx ++  and a highlight of the dangers of low diversity
20:06:23 <sdague> diversity:danger
20:06:31 <mtreinish> ttx: but in this case I agree with the single vendor losing interest
20:06:39 <mtreinish> I'm thinking more for the future
20:06:41 <thingee> mtreinish: missing releases is pretty bad
20:06:47 <annegentle> I think we have good input since Min answered, but did wonder about "who's next"
20:06:50 <ttx> mtreinish: missing the release, the summit, the IRC meetings and no ML discussion is pretty much clear cut to me
20:07:01 <sdague> yeh, it seems pretty straight forward
20:07:12 <ttx> I mean, they can totally be back if they pick it up
20:07:13 <mestery> ttx: Seems about right to me too
20:07:31 <thingee> annegentle: not our problem of who is next. it's retired and someone can revive.
20:07:38 <ttx> but fact is, they have not the level of activity that is expected of openstack projects at this point
20:07:46 <dhellmann> 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 <edleafe> Making it easier for projects to come in should also make it easier for them to go out
20:08:03 <ttx> dhellmann: yes, in that case it's more of a combination of things
20:08:04 <dtroyer> edleafe: ++
20:08:11 <ttx> the project also happens to be not mature
20:08:12 <mestery> edleafe: ++
20:08:19 <ttx> edleafe: exactly
20:08:20 <mordred> edleafe: ++
20:08:22 <thingee> 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 <dhellmann> ttx: right, that's why I don't think we want too many hard-and-fast rules
20:08:24 <sdague> dhellmann: but the whole oslo project isn't going to dry up
20:08:27 <ttx> greasing the door goes both ways
20:08:32 <sdague> dhellmann: agreed
20:08:40 <dims> ttx +1
20:08:41 <johnthetubaguy> dhellmann: stability is a good point, when we come to making the rules
20:08:47 <dhellmann> 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 <annegentle> dhellmann: ttx: ok so rules/lists/metrics won't really work
20:08:49 <sdague> 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 <annegentle> case by case then
20:09:12 <edleafe> another way to look at it: if they applied today for the big tent, would we feel that they measure up?
20:09:20 <sdague> fortunately we've got 13 elected representative humans that have human judgement
20:09:24 <dhellmann> sdague : ++
20:09:31 <ttx> annegentle: yes. My rule of thumb for the start is... having a tc member who cares enough to propose the removal
20:09:32 <dims> ++ sdague
20:09:34 <edleafe> sdague: yes!
20:09:41 <thingee> 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 <mestery> sdague: yes!
20:09:46 <sdague> I think coming up with an algorithm instead of just "representative humans" is the wrong thing to do
20:10:01 <ttx> It's not "you miss a release, you're out"
20:10:14 <dhellmann> 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 <thingee> dhellmann: that's not what we're saying
20:10:29 <ttx> It's just one symptom amongst others
20:10:32 <thingee> dhellmann: that is just one of the things
20:10:40 <mtreinish> ttx: that's all I wanted to clarify. Because the commit msg could be read that way
20:10:46 <dhellmann> ok. that was the one I caught as it went past
20:11:06 <ttx> mtreinish: oh, yes, there is no rule we are following here
20:11:20 <dims> we are not talking about archiving. just remove from governance. so easy +1 for removal
20:11:50 <dhellmann> 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 <sdague> dhellmann: it's all still human judgement
20:12:06 <dhellmann> ok, good
20:12:09 <ttx> agreed
20:12:09 <sdague> I think that's our algorithm
20:12:12 <sdague> a TC vote
20:12:20 <ttx> just a pile of symptoms and a gut call
20:12:24 <sdague> yes
20:12:39 <ttx> That case was arguably easy
20:12:45 <ttx> which is why I posted it first
20:12:47 <thingee> dims: you can bring something out of archive. Just like you can bring something out of retirement.
20:12:58 <ttx> ok, looks like we have majority there
20:13:02 <notmorgan> ttx: can we swap the next two topics (before we swap)
20:13:06 <dims> thingee true
20:13:09 <fungi> also, unlike int the beforetime, we can take a project out of openstack without having to rename its git repos
20:13:17 <notmorgan> ttx: the url entry should be less contentous/take less time.
20:13:18 <ttx> notmorgan: sure
20:13:38 <flaper87> notmorgan: ++
20:13:52 <annegentle> yeah sounds good to swap
20:14:01 <dims> fungi : was thinking about http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project steps
20:14:21 <ttx> ok, so, I'll approve it now
20:14:48 <ttx> approved
20:15:06 <ttx> #topic Adds a contributordocs: URL entry to projects.yaml
20:15:14 <ttx> #link https://review.openstack.org/316396
20:15:24 <ttx> This is still in progress work, Anne do you have all you need to make progress ?
20:15:29 <annegentle> as I said in the review, it's a draft.
20:15:29 <notmorgan> i'm generally for this, needs a little cleanup though.
20:15:35 <mestery> yes
20:15:38 <notmorgan> but it's def. going the right way
20:15:41 <mestery> One tag removal in there
20:15:44 <mestery> notmorgan: ++
20:15:47 <annegentle> mestery: yes nice catch
20:15:54 <mestery> annegentle: nice work though!
20:15:59 <annegentle> I'd like to figure out how to deal with projects with multiple repos with docs?
20:16:08 <mtreinish> annegentle: yeah, that's what I was just gonna ask
20:16:11 <notmorgan> annegentle: make it a list?
20:16:13 <annegentle> would it be better to put a docs: line for each repo?
20:16:24 <mtreinish> because things like qa and infra have lots of very different projects
20:16:26 <notmorgan> annegentle: hm. probably per-repo
20:16:27 <annegentle> someone tell me YAML solutions here :)
20:16:29 <dims> annegentle : where are we going to render/use this info?
20:16:32 <flaper87> annegentle: haven't read the latest PS but, did you find a way to avoid adding the repos with `None` urls ?
20:16:33 <dhellmann> annegentle : or per deliverable
20:16:36 <amrith> 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 <notmorgan> dhellmann: ++
20:16:46 <flaper87> that said, I'm certainly in favor of this
20:16:58 <notmorgan> dhellmann: yeah per deliverable would be my vote
20:17:02 <annegentle> 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 <notmorgan> annegentle: you can, but None is fine as well.
20:17:22 <notmorgan> i like the explicits
20:17:23 <dhellmann> annegentle : does the yaml parser turn "None" into a None value?
20:17:24 <johnthetubaguy> +1 for adding None explicitly, its kinda nice
20:17:26 <annegentle> amrith: not sufficient if I want to expand beyond contributor docs
20:17:33 <annegentle> dhellmann: not sure, good question
20:17:39 * dims envisions a pypi like interface for all this info
20:17:42 <notmorgan> dhellmann: it should. if not we should make sure we're passing the right thing in
20:17:46 <dhellmann> annegentle : because I wouldn't want the rendering code to have a special case for that
20:18:12 <amrith> annegentle, if that's the case should the link be at the project level or the release level?
20:18:12 <sdague> dhellmann: I'm nearly sure that it does
20:18:20 <notmorgan> i think "null" is correct
20:18:23 <notmorgan> not "none"
20:18:25 <annegentle> is there a way to say docs: and then what type? in YAML?
20:18:28 <notmorgan> http://yaml.org/type/null.html
20:18:29 <sdague> notmorgan: yeh, that might be
20:18:35 <johnthetubaguy> notmorgan: good point
20:18:36 <dhellmann> sdague : possibly, but ... what notmorgan said
20:18:48 <annegentle> amrith: you might be onto something there
20:18:54 <dhellmann> we can deal with that when we update the rendering code
20:18:54 <flaper87> annegentle: cool
20:18:57 <annegentle> amrith: release level perhaps
20:19:17 <amrith> annegentle, maybe both?
20:19:22 <ttx> annegentle: ok, so you will iterate on the review
20:19:25 <annegentle> ok I probably have enough to do another passthrough... for more reviews
20:19:28 <annegentle> yeah
20:19:30 <notmorgan> annegentle: :)
20:19:33 <annegentle> thanks
20:19:34 <ttx> annegentle: sounds good
20:19:34 <amrith> thx annegentle
20:19:44 <mtreinish> notmorgan: heh, I like the definition there, "devoid of value"
20:19:49 <notmorgan> mtreinish: hehe
20:19:50 <ttx> just wanted to make sure you had all you needed to make progress
20:19:58 <ttx> next topic...
20:20:04 <ttx> #topic Add golang as an approved language
20:20:04 <amrith> 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 <ttx> #link https://review.openstack.org/312267
20:20:20 <ttx> 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 <ttx> Like Monty I tend to lose sleep over them over the past week
20:20:32 * notmorgan steals edleafe's popcorn
20:20:38 <dhellmann> ttx: I think that's one thing we can all agree on.
20:20:43 <mordred> ++
20:20:43 <ttx> Like there must be a solution that is perfect but I can't find it
20:20:43 <dims> ttx : yep, don't like it at all
20:20:52 <annegentle> I'll be honest, I feel backed in a corner.
20:20:58 <ttx> Most TC members voiced their position on this one, I'll try to summarize
20:21:17 <notmorgan> so fwiw, i've changed my view somewhat.
20:21:24 <ttx> Flavio raised that opening the floodgates to another language is not the right call at this time for OpenStack
20:21:34 <dougwig> ttx: any chance this can be tabled until the TC tackles defining openstack?
20:21:35 <flaper87> o/
20:21:39 <ttx> As we are still struggling with driving more consistency and share more things between components of OpenStack
20:21:40 <annegentle> Timing, urgency, emotional ties... rather than data-driven.
20:21:44 <ttx> dougwig: we kind of already did
20:21:52 <ttx> a long time ago
20:21:57 <notmorgan> 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 <ttx> 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 <notmorgan> dougwig: this is about language first, scope is a separate convo
20:22:13 <edleafe> Rockyg: mmmmmm
20:22:15 <notmorgan> if it is being revisited
20:22:23 <ttx> 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 <ttx> mestery advocated that we should just let the projects use the best tools.
20:22:53 <ttx> 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 <ttx> dims said the TC should vet which projects did enough due diligence to get to use Go and which didn't
20:23:12 <mestery> The alternative is to say they are not openstack if they use a language like Go I guess
20:23:14 <ttx> which on the surface sounds like a nice compromise option
20:23:21 <dims> ttx : cross-project with guidance from TC
20:23:22 <flaper87> 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 <ttx> 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 <ttx> mordred was very eloquent and I wouldn't dare summarize his views, maybe he can
20:23:49 <dims> ttx ack
20:23:59 <mordred> ttx: no chance - that took me a long time to write
20:23:59 <flaper87> 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 <dhellmann> yeah, I can't imagine how we could effectively police the "appropriate" use
20:24:03 <notmorgan> i am very very very very very very very against the TC saying "you can use go" individually
20:24:06 <flaper87> mordred: lol
20:24:11 <thingee> dhellmann: +1
20:24:13 <notmyname> 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 <mordred> ttx: I hate both choices, I just think one is a little less bad than the other
20:24:16 <ttx> notmorgan: that we agree on
20:24:30 <flaper87> notmorgan: yup, not the plan
20:24:32 <ttx> 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 <mestery> flaper87: Some not all, thus my comment was relevant :)
20:24:41 <mordred> notmorgan: ++
20:24:42 <ttx> Any others I missed ?
20:24:44 <mugsie> and we have in the past just let other languages slip in, and said nothing
20:24:47 <edleafe> 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 <ttx> I think thingee is also on flaper87 option
20:24:52 <flaper87> mugsie: yup
20:24:54 <mestery> mugsie: What? Blasphemy
20:25:04 * ttx ctaches up with recent reviews
20:25:06 <flaper87> mugsie: that was for mestery
20:25:12 <mestery> lol :)
20:25:21 <dims> dhellmann : cross-project spec and debate at cross project meeting
20:25:21 <mugsie> flaper87: tab+m?
20:25:27 <notmyname> 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 <flaper87> mugsie: guilty as charged
20:25:44 <notmorgan> 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 <mestery> I like dtroyer's comment, it was spot on I think, and aligns with what dougwig mentioned too.
20:26:01 <edleafe> notmyname: that was more for Designate's concerns
20:26:02 <notmorgan> i'm fine with it at this point, regardless of the direction taken.
20:26:06 <thingee> 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 <sdague> 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 <ttx> mugsie made good points on more fragemntation at specific project level vs. more fragmentation at openstack-level
20:26:20 <flaper87> thingee: ++
20:26:22 <notmorgan> thingee: and that as the add on point
20:26:32 <flaper87> notmorgan: +! on making the decision today
20:26:34 <dhellmann> thingee : we don't currently have any formal restrictions about the language of third-party dependencies, do we?
20:26:35 <mestery> sdague: Fair point
20:26:36 <dims> thingee : i'd like people to do their work here, not go elsewhere..
20:26:44 <annegentle> 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 <notmyname> does "not in the tent" mean that it's not in the openstack/* namespace at all?
20:26:51 <thingee> dhellmann: nope
20:26:59 <flaper87> notmyname: nope
20:27:00 <mordred> notmyname: the openstack/ namespace does not convey meaning
20:27:03 <notmorgan> notmyname: no, just not in governance
20:27:12 <devananda> 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 <mugsie> 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 <notmorgan> notmyname: absolutely still possible to be in openstack/* namespace if they want to be :)
20:27:27 <dhellmann> devananda : as long as you can pip-install them
20:27:29 <thingee> 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 <notmorgan> it is up to the project to make that choice.
20:27:33 <mugsie> notmorgan: is it?
20:27:37 <mordred> dhellmann: or apt/yum
20:27:40 <dtroyer> mordred: as much as I wish that were true, it is not
20:27:41 <devananda> dhellmann: I can't "pip install mysql" - but we depend on mysql
20:27:47 <dhellmann> mordred : or import from python, I guess I should say
20:27:49 <devananda> mordred: right. that's better
20:27:50 <anteaya> mugsie: it is not the number it is the workload
20:27:53 <dhellmann> devananda : mysql is not a lib
20:27:55 <mordred> dtroyer: it may imply meaning to people, but it does not convey chosen meaning
20:28:01 <notmorgan> 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 <anteaya> mugsie: and those that do cross project have had an increaased workload
20:28:08 <edleafe> mysql is also not part of OpenStack
20:28:09 <flaper87> mordred: +1
20:28:20 <mugsie> anteaya: the point raised in the review was loack of cross-virtical-project developers
20:28:26 <anteaya> right
20:28:37 <dims> thingee : ttx : do we let code be in openstack/ git and use CI but just not in governance?
20:28:38 <ttx> "not in the tent" just means "not under the TC rule"
20:28:41 <notmorgan> 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 <ttx> which is kind of what you want here
20:28:46 <anteaya> and the ones that are currently active have an increased workload
20:28:48 <mordred> dims: yes. we have tons of things like that
20:28:50 <sdague> dims: yes
20:28:55 <dims> whew ok
20:29:09 <mugsie> notmorgan: yeah - I knew that, but the issue around community costs is still going to happen then
20:29:27 <thingee> dims: projects not part of the governance can already do that
20:29:39 <cdent> having lots of things that are not OpenStack™ in /openstack is bound to cause external folk a ton of confusion
20:29:40 <flaper87> and some actually do already, IIRC
20:29:40 <ttx> projects can continue to use openstack infrastructure and prove us wrong
20:29:45 <notmorgan> mugsie: somewhat. it doesn't convey ATC, doesn't convey other benefits, doesn't convey VMT coverage, etc
20:29:48 <notmyname> 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 <cdent> s/a ton of/increasaed
20:29:53 <anteaya> and if the workload decreased to a managable amount we might get more folks doing cross project work
20:30:03 <dims> thingee : that softens the blow
20:30:12 <anteaya> cdent: it already is
20:30:21 <devananda> 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 <annegentle> 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 <dims> not sure what practical difference it makes to infra/docs etc
20:30:30 <thingee> cdent: I disagree, we have things not part of openstack that are dependencies for certain use cases.
20:30:38 <notmorgan> devananda: yes, better phrasing
20:30:59 <cdent> thingee: I'm just reporting what people tell me
20:31:00 <devananda> notmorgan: maybe I'm being obtuse, but what's the practical difference, then?
20:31:05 <notmorgan> notmyname: i would almost argue that should be the case in either case.
20:31:05 <notmyname> 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 <thingee> cdent: I'm just reporting what is happening today :) - I mean libvirt is fine for example
20:31:36 <edleafe> cdent: that was recognized when we got rid of stackforge
20:31:41 <ttx> notmyname: the trick is how to allow you to do that without breaking the rest of openstack with crazy Golang rewrites
20:31:49 <dhellmann> 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 <notmorgan> 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 <notmorgan> devananda: and a marketing thing.
20:32:12 <flaper87> dhellmann: ++
20:32:19 <notmyname> 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 <annegentle> notmyname: is there a technical problem with the dividing line? (really trying to understand, this is not a judging stance)
20:32:28 <mugsie> 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 <flaper87> dhellmann: notmyname but that's something we can work together on with the infra team and whatnot if needed
20:32:43 <mugsie> what is the difference then
20:32:44 <dims> dhellmann : i dont know how doing this way in any way reduces burden on cross project teams...
20:32:55 <notmyname> 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 <ttx> 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 <jroll> 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 <annegentle> notmyname: ok
20:33:12 <ttx> which is why it's not a nideal solution at all
20:33:14 <flaper87> annegentle: notmyname: happy to share the contents of that email
20:33:14 <johnthetubaguy> cdent: agreed the current state of /openstack is confusing, points to the deeper questions we still need to answer here
20:33:17 <mordred> jroll: community
20:33:25 <notmyname> flaper87: I would totally support that
20:33:29 <jroll> mordred: noted, the wording threw me
20:33:33 <annegentle> flaper87: notmyname: thanks that will help me understand
20:33:47 <flaper87> annegentle: notmyname: coolio, I'll probably just put everything on an etherpad
20:33:49 <devananda> 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 <notmyname> flaper87: annegentle: I can put it on the ML after the meeting
20:34:00 <dims> devananda : me too
20:34:01 <notmorgan> devananda: docs team, VMT, etc
20:34:09 <ttx> 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 <jroll> devananda++
20:34:12 <devananda> notmorgan: docs, VMT, etc, already don't have to care about new projets
20:34:16 <jroll> ^
20:34:18 <devananda> notmorgan: so why would they care about this one?
20:34:19 <annegentle> I basically still sense that the problem is complex, the solution proposed is too simplified, so we all can't agree.
20:34:20 <clarkb> devananda: dims we spend a significant amount of time hand holding every little piece of dev
20:34:26 <notmorgan> devananda: but the non-governance repos can't ask for these resources
20:34:31 <dhellmann> 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 <ttx> annegentle: yes
20:34:55 <notmorgan> devananda: in an official capacity that is
20:35:02 <dims> clarkb : saying, you can create new repos with go code and use CI/infra etc..does not reduce that burden
20:35:09 <anteaya> 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 <devananda> 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 <dhellmann> devananda : that resulted in "the install guide" being renamed and repurposed, for example, to make space for other guides
20:35:21 <clarkb> dims: yes it does I dont have to debug your tests when they fail
20:35:28 <anteaya> there is a lot of repeating of events that goes along with cross project work
20:35:38 <johnthetubaguy> 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 <clarkb> or teach you how to use sphinx etc
20:35:51 <mugsie> clarkb: even for some big tent projects - they dont get that
20:35:51 <dims> clarkb : interesting distinction
20:35:53 <notmorgan> devananda: that is part of the deal. also marketing from the foundation and ATC etc conveyance would be excluded
20:35:54 <devananda> 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 <clarkb> mugsie: they totally so...
20:36:09 <clarkb> I spend a large chunj of my time debugging your code
20:36:12 <devananda> clarkb: so adding golang _at all_ carries that shared debugging burden
20:36:16 <dhellmann> johnthetubaguy : possibly. expectations for something likes i18n might be lower if the project isn't official.
20:36:22 <notmorgan> dhellmann: ++
20:36:26 <johnthetubaguy> devananda: true
20:36:28 <johnthetubaguy> oops
20:36:30 <devananda> regardless of TC oversight of golang-based projects
20:36:30 <dims> clarkb : so we'll let folks use other languages instead of swift in new git repos?
20:36:32 <johnthetubaguy> dhellmann: true
20:36:34 <ttx> 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 <ttx> or drive any sort of cross-project initiative
20:36:48 <dims> oops golang
20:36:59 <devananda> ttx: ok, thanks. that is what I envision, but not what notmorgan was claiming above
20:37:03 <Guest43585> why not have two separate object storage projects that implement the object storage API defined by the object storage program?
20:37:12 <clarkb> dims: we already do... java, Go, php, even objective C I tink
20:37:14 <dhellmann> devananda : that's a good point. and projects may choose not to depend on unstable unofficial projects for that reason.
20:37:26 <devananda> scotticus: that's not what was proposed, nor what we're discussing
20:37:29 <jbryce> 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 <notmorgan> 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 <notmorgan> jbryce: my words are insufficient to cover the fidelity there
20:38:32 <notmorgan> jbryce: it may be the best experience to do this with this dependency
20:38:33 <notmyname> 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 <devananda> notmyname: * and on the same shared infrastructure :)
20:38:57 <notmorgan> notmyname: i'm going to go out and say RDBMS is required.
20:39:03 <ttx> 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 <notmorgan> notmyname: and in most cases that is mysql
20:39:29 <flaper87> ttx: or developed by openstack people out side openstack and inside openstack that depend on openstack
20:39:39 <flaper87> that came out messy but you get my point
20:39:45 <mordred> we typically do not depend on external _source_ repositories. we depend on released binaries of things
20:39:46 * flaper87 hopes
20:39:51 <clarkb> (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 <mordred> so we do not install mysql from source to install openstack
20:39:58 <annegentle> 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 <dims> clarkb :) no worries
20:40:03 <mordred> we apt-get/yum install mysql
20:40:06 <notmyname> 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 <mordred> it's a dependency
20:40:26 <annegentle> clarkb: yes, that.
20:40:36 <jroll> clarkb: <3
20:40:39 <ttx> notmyname: yes, that is why I don't like this solution. I just hate it less than the other option
20:40:41 <devananda> clarkb: and thank you :)
20:40:42 <flaper87> annegentle: that pretty much summarizes my comment and concern.
20:41:13 <notmyname> ttx: the other option being golang is ok? (which everyone has agreed is probably the right answer, technically)
20:41:46 <edleafe> notmyname: technical merits aren't the only (or most important) thing
20:42:00 <devananda> 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 <ttx> 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 <dims> 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 <flaper87> the technical merits is not what we're weighting more here, fwiw
20:42:18 <dims> we are essentially saying that here
20:42:30 <ttx> so it's about project-centric pain vs. cross-project pain. You can actually see that in the vote spread
20:42:39 <annegentle> dims: you already don't need that.
20:42:41 <edleafe> dims: or rather, you really need to demonstrate why you *can't* write it in Python
20:42:41 <scotticus> dims: i feel like i have a solution for that :P
20:42:42 <jbryce> 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 <thingee> dims: I think that would probably be the result of this discussion ... a resolution of some sort
20:42:46 <scotticus> or proposal.
20:42:58 <dims> annegentle : we don't say it explicitly, we should now that we have a decision here
20:43:02 <devananda> 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 <annegentle> dims: it's that this proposal is written too black-and-white.
20:43:06 <dims> thingee ++
20:43:27 <mordred> devananda: I believe you stated that very clearly
20:43:39 <flaper87> devananda: ++
20:43:40 <dims> annegentle : don't know how else it could have been written :(
20:43:46 <notmyname> annegentle: how so? what shoudl change?
20:43:57 <jbryce> 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 <annegentle> dims: notmyname: More like the considerations upfront than the "contributors are in pain let's alleviate that"
20:44:10 <devananda> jbryce: ++
20:44:25 <ttx> jbryce: yes, and "who is openstack" is defined by the practices that we share
20:44:32 <flaper87> ttx: ++
20:44:37 <annegentle> notmyname: though what I also would dive into is what was the order of javascript additions?
20:44:44 <dims> annegentle : don't know if it would have changed the outcome
20:44:47 <jroll> 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 <ttx> and I feel like this is extending it beyond our capacity to absorb it
20:44:59 <annegentle> notmyname: it's possible my history order is incorrect
20:44:59 <anteaya> ttx: ++
20:45:44 <ttx> I don't like yes, I don't like no, and I don't like stalling. Someone help me
20:45:58 <scotticus> 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 <johnthetubaguy> ttx: it doesn't help, but I am in the same camp right now
20:46:24 <mordred> scotticus: no
20:46:31 <notmyname> it's never been that scotticus
20:46:31 <mordred> scotticus: that was decided a very long time ago
20:46:36 <edleafe> scotticus: no, that was decided a long time ago
20:46:43 <mordred> edleafe: jinx
20:46:43 <edleafe> mordred: jinx
20:46:44 <dims> everyone abstain? (looking at @notmorgan)
20:46:45 <flaper87> 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 <mordred> hahaha
20:47:06 <notmorgan> 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 <notmyname> 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 <notmorgan> dims: i agree strongly with both notmyname and mordred
20:47:23 <jbryce> 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 <ttx> 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 <notmorgan> dims: and since i cannot and CANNOT make a case here right now, i will support the decision made.
20:47:42 <dims> agree
20:47:43 <jbryce> the swift team has set a pretty high bar for making that justification
20:47:48 <carolbarrett> 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 <edleafe> jbryce: exactly. Demonstrate why you need Go or anything else
20:47:59 <dtroyer> I think the TC getting a bit more involved in actually guiding projects is not a bad thing at all
20:47:59 <jbryce> literally over more than a year of time, testing, data gathering
20:48:03 <ttx> edleafe: to whom ?
20:48:08 <notmorgan> dtroyer: ++
20:48:13 <edleafe> ttx: to the TC
20:48:19 <carolbarrett> dtroyer ++
20:48:27 <edleafe> ttx: that is a technical decision, no?
20:48:28 <notmyname> edleafe: has swift not done that sufficiently yet?
20:48:28 <devananda> 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 <amrith> dtroyer ... ++
20:48:39 <jbryce> 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 <annegentle> devananda: apparently there's a document about that
20:48:46 <edleafe> notmyname: For swift, yes. For Designate, no
20:48:53 <devananda> annegentle: oh?
20:48:56 <ttx> edleafe: I really fear we'll be back into granting exceptions, and judging projects technical analysis
20:48:56 <dims> 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 <annegentle> devananda: I asked something similar and flaper87 and notmyname can send
20:49:12 <dims> will give a say to everyone in the process on a specific projects plans
20:49:16 <ttx> like swift is pretty clear-cut, I totally get why they need go. What about designate ?
20:49:17 <notmyname> 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 <johnthetubaguy> ttx: maybe that how we don't stall and don't decide right now?
20:49:33 <edleafe> notmyname: hence the dislike of making all Go (or anything else) accepted by default
20:49:43 <devananda> notmyname: ok, thanks
20:50:07 <dims> 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 <notmorgan> dims: doubtful.
20:50:19 <ttx> 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 <anteaya> dims: noone likes to be the police
20:50:26 <edleafe> 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 <notmyname> 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 <flaper87> dims: fwiw, I'd prefer the TC to do that in this case
20:50:43 <notmorgan> notmyname: fair data point
20:50:52 <thingee> no, I'm not for special case. I'm really unhappy with the previous special cases.
20:50:53 <dtroyer> flaper87: ++
20:50:58 <flaper87> ttx: I honestly would prefer to stay consistent in this case
20:51:03 <flaper87> so no special case
20:51:08 <notmyname> thingee: I've never asked for this to be a special case for swift :-)
20:51:36 <dims> that's all the ideas i had :)
20:51:37 <notmorgan> 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 <flaper87> time check
20:51:50 <thingee> 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 <edleafe> notmorgan: agree
20:51:58 <mordred> thingee: ++
20:52:05 <notmorgan> stalling is not going to answer it
20:52:07 <johnthetubaguy> so in a years time, we will know the impact it has had on swift
20:52:08 <devananda> thingee: +1
20:52:08 <ttx> So I'm open for someone (dims) to propose a mechanism by which we would be able to vet projects individually
20:52:16 <dtroyer> thingee: ++ please do something, and then follow though on it
20:52:18 <notmorgan> bascially a stall here is a -1 imo
20:52:20 <flaper87> thingee: ++
20:52:28 <dims> ttx : very cool. i am open to that
20:52:30 <johnthetubaguy> its possible swift will build a group of folks that work well in both go and python
20:52:37 <johnthetubaguy> or they might decide to move everything to go
20:52:38 <edleafe> dims: I'd love to help
20:52:40 <devananda> johnthetubaguy: it's already been in discussion for a long time, and the impact is becoming clear to that project
20:52:48 <ttx> but the current resolution can' tpass at this stage, unless a few people who voted -1 decide to change their vote
20:52:50 <dims> edleafe : ack
20:52:53 <flaper87> dims: ttx until that happens, I think we should stick with what's been voted on
20:53:14 <ttx> we have a majority to deny this as it stands
20:53:16 <notmorgan> ttx: so i think the answer is no to golang. by the nature of the votes.
20:53:18 <amrith> dims, I'm interested in that as well; am happy to help with that proposal.
20:53:25 <dims> amrith : ack
20:53:28 <thingee> ok, so we stall because some member abstain and need more time?
20:53:28 <notmyname> 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 <dims> notmyname : i'll need your help as well
20:54:06 <dtroyer> dims: me too
20:54:14 <notmyname> dims: with what now? I missed somethign it seems
20:54:29 <dims> notmyname : "<ttx>	So I'm open for someone (dims) to propose a mechanism by which we would be able to vet projects individually"
20:54:29 <notmorgan> notmyname: basically special case with a clear set of guidelines for anyone wanting it in the future
20:54:41 <ttx> notmyname: propose a mechanism for selective access to extra languages
20:54:41 <notmorgan> notmyname: so it's "here is how you get approval for this"
20:55:13 <notmyname> ok
20:55:20 <thingee> dims: I and other members have expressed we'd not like the TC to be part of that process.
20:55:23 <jroll> 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 <notmyname> 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 <ttx> since it looks like we can't resolve ourselves to accept blank approval
20:55:32 <notmorgan> ttx: so lets call it "no to golang in this proposal".
20:55:33 <devananda> jroll: ++
20:55:33 <thingee> dims: to which others expressed the community should vet
20:55:36 <mugsie> jroll: ++
20:55:36 <dims> thingee : yep, i mentioned that already
20:55:38 <thingee> which I also don't think is productive
20:55:41 <annegentle> 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 <jroll> fwiw, I'm on the 'allow' side of this line but don't get a vote
20:56:02 <jbryce> thingee: i think at least one other tc member said he would like to be
20:56:04 <devananda> 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 <edleafe> jroll: small cracks are much better than chasms
20:56:14 <dims> annegentle : agree
20:56:28 <thingee> jbryce: I'd hate to repeat pre big tent unproductive discussions.
20:56:29 <devananda> edleafe: small cracks widen over time
20:56:30 <jroll> edleafe: I disagree that it would be any worse allowing anyone to use go
20:56:35 <carolbarrett> If the TC won't take the role of making decisions about governance across the projects, then who should?
20:56:51 <carolbarrett> I thought that was a key part of the TC charter
20:56:53 <jroll> edleafe: or any "larger of a crack", using your analogy
20:56:55 <devananda> carolbarrett: the TC does make decisions across projects
20:56:59 <notmyname> 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 <sdague> 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 <notmorgan> ttx: so.
20:57:12 <devananda> carolbarrett: but blessing exceptions to its own rules? that's not what the TC is about
20:57:13 <notmorgan> if i am reading this:
20:57:16 <ttx> notmorgan: I'm lost
20:57:23 <notmorgan> 1) No to golang, blanket is what i am hearing
20:57:28 <notmorgan> please correct me if i am wrong
20:57:34 <ttx> yes, I think that's fair
20:57:42 <carolbarrett> devananda: sounds like a cross-project governance decision to me...
20:57:42 <jroll> 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 <jbryce> that’s where the votes on the review sit currently, yes
20:57:47 <notmorgan> 2) dims, notmyname, etc will come up with a guideline to cover access for other languages
20:57:50 <dims> 3 mins time check
20:58:03 <notmorgan> something we can judge the projects by
20:58:07 <sdague> jroll: I agree, I don't think it's better. And wouldn't really feel any different about it.
20:58:13 <mordred> 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 <notmorgan> 3) Swift is not being told no to "golang"
20:58:20 <jroll> sdague: fair enough
20:58:24 <notmorgan> mordred: i dis like it a lot
20:58:27 <flaper87> 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 <mordred> notmorgan: right. I'm just annotating
20:58:36 <flaper87> but I could be wrong, need to read it first
20:58:37 <notmorgan> mordred: ++
20:58:38 <ttx> notmorgan: hmm, expand on 3 ?
20:58:51 <mugsie> well, i think this is going to end in the current language policy
20:58:56 <notmorgan> 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 <mordred> 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 <ttx> because we are not really saying yes either ;/
20:59:05 <notmyname> 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 <mestery> notmorgan: 3 seems to conflict with 1
20:59:09 <mugsie> use python, want something else go to the TC
20:59:11 <notmorgan> not being told to "go away and split off"
20:59:16 <notmorgan> explicitly
20:59:19 <notmorgan> it was more of 2a.
20:59:21 <notmorgan> not 3
20:59:29 <flaper87> notmorgan: yeah
20:59:29 <notmorgan> that was what i read from this meeting.
20:59:30 <ttx> notmyname: I'm fine with that yes
20:59:37 <ttx> I think we need a few extra minutes
20:59:50 <ttx> next meeting if any could move to another room
20:59:51 <notmorgan> i was just summarizing what i saw in the meeting
21:00:02 <ttx> although that makes me getting drunk to forget all this later away
21:00:13 <flaper87> notmorgan: sounds like a fair summary to me
21:00:19 <anteaya> ttx: I don't see a conflict in the ical schedule
21:00:23 <flaper87> ttx: I'm ahead of you on that ;)
21:00:31 * flaper87 acts normal
21:00:40 <edleafe> ttx: maybe we should all have a few drinks, and then continue :)
21:00:44 <johnthetubaguy> yeah, I think that is a good summary, and its not self-consistent really, hence the issue
21:00:44 <dims> we need to find a reasonable way to vet proposals and make aware of people the deeper issues behind choices
21:00:48 <ttx> So, summary
21:01:08 <cdent> So, something I'd like to be more clear about: What does swift gain by being in OpenStack?
21:01:18 <mordred> 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 <mordred> 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 <flaper87> 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 <notmorgan> 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 <ttx> 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 <jbryce> 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 <ttx> jbryce: yes
21:02:16 <flaper87> Rockyg: yo, don't forget me !
21:02:19 <mordred> jbryce: ++
21:02:24 <thingee> jbryce: +1
21:02:28 <ttx> I think that there is a majority at the TC that is not comfortable with Go blanket access
21:02:30 <notmorgan> jbryce: yes.
21:02:35 * Rockyg passes out glasses
21:02:35 <amrith> heh heh ... Rockyg gives edleafe butter and mordred single malt :)
21:02:37 <edleafe> 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 <ttx> 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 <mordred> ttx: right. but it's possible that that is less bad to people generally
21:03:06 <ttx> but that eeds some work, basically a new framework for us to accept language additions
21:03:13 * amrith carries dims
21:03:14 <mordred> depending on what magic dims and notmyname write up
21:03:15 <devananda> 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 <ttx> mordred: yeah, maybe, devil is in the details
21:03:33 <ttx> devananda: but that still may be the less worse option htere
21:03:40 <mordred> 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 <jbryce> at the same time do most people acknowledge that hummingbird provides a technical improvement for swift?
21:03:42 <annegentle> cdent: marketing events infra test docs automation debugging frameworks a community and more. but no commas ever. :)
21:03:49 <dtroyer> devananda: which is too bad because I think that is its job…
21:04:00 <mordred> jbryce: I do not think anyone disputes that
21:04:06 <ttx> so as far as this patricular resolution is concerned, I think we need to deny it
21:04:07 <flaper87> jbryce: mordred ++
21:04:17 <edleafe> jbryce: I think that's the point: swift demonstrated clearly why it was necessary
21:04:19 <devananda> dtroyer: we were in that position before the big-tent .. it's not great
21:04:20 <annegentle> jbryce: that's not the heart of the belief set this change brings
21:04:23 <ttx> jbryce: I'd agree to that.
21:04:23 <flaper87> ttx: and wait for what dims and others will work on
21:04:42 <dtroyer> devananda: as implemented then, right.  I think we're worse off now
21:04:50 <ttx> 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 <mordred> jbryce: the vexxing part is balancing the tech and the non-tech results - since the two aren't directly comparable
21:04:52 <devananda> dtroyer: constructively, I disagree
21:05:08 <mordred> 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 <notmorgan> 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 <notmorgan> mordred: also +10000
21:05:38 <mordred> dhellmann: welcome back!
21:05:39 <jbryce> 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 <notmyname> jbryce: yes. absolutely
21:06:07 <fungi> 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 <flaper87> jbryce: yup, that was the feedback we got
21:06:08 <annegentle> jbryce: notmyname to me it's unclear why that separation is untenable
21:06:09 <ttx> 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 <carolbarrett> 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 <jbryce> mordred: yeah i get that part. as i said to ttx and thingee earlier i’m torn myself because of it
21:06:39 <devananda> carolbarrett: it's not about making decisions or notmaking decisions
21:06:40 <anteaya> mordred: safe travels
21:06:52 <annegentle> fungi: yes I wondered that as well
21:07:09 <notmyname> 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 <ttx> 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 <notmyname> fungi: and the original authors have about a hundred other thigns on their plate too
21:07:29 <fungi> notmyname: but the swift community is contributing to it?
21:07:35 <notmyname> fungi: some
21:07:41 <notmyname> fungi: just like we do to eventlet
21:07:44 <carolbarrett> devananda: would be interested to have a follow-up conversation to better understand your viewpoint
21:07:48 <fungi> are swift team members its primary contributors now?
21:07:52 <devananda> carolbarrett: be happy to
21:08:01 <ttx> s/rating/granting
21:08:02 <notmyname> fungi: hard to say. the move is recent
21:08:13 <carolbarrett> devananda: Thanks
21:08:33 <ttx> timecheck again
21:08:42 <notmyname> ttx: that sounds like restarting this discussion and having it again with some different details
21:08:47 <ttx> I don't think we'll get any further today
21:08:49 <notmorgan> ttx: 8min over. we can continue for a few more.
21:08:59 <notmyname> for the record, I think rejecting this proposal is the wrong choice
21:09:57 <ttx> noted
21:10:05 <annegentle> notmyname: recorded
21:10:10 <notmyname> (wanted that on the record so in 5 years when meeting logs are brought up again, it'll be there) ;-)
21:10:15 <notmorgan> notmyname: hehe
21:10:16 <annegentle> notmyname: heh nice
21:10:19 <ttx> notmyname: and maybe prove you right
21:10:21 <dims> :)
21:10:26 <Rockyg> should add something as a comment that a different proposal will appearsoon
21:10:32 <notmorgan> ttx: if we need to wait 5 years... i'm going to be sad.
21:10:44 <ttx> ok, I'll comment on the review to call it, and close this meeting
21:10:52 <ttx> unless anyonte has items for open discussion
21:10:57 <notmyname> yes, one final thing please
21:11:04 <ttx> #topic Open discussion
21:11:08 <ttx> notmyname: go for it
21:11:27 <notmyname> 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 <notmorgan> notmyname: that is how i understand it.
21:11:47 <notmyname> no mandate from the TC that swift needs to split into differnet projects, one in and one out of openstack
21:11:51 <EmilienM> (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 <ttx> for the record, I'm really losing sleep over this. Sometimes I wish I cared less
21:12:15 <ttx> notmyname: nothing of the sort
21:12:20 <devananda> 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 <dhellmann> ttx: thanks for the summary, there was a lot of scrollback
21:12:33 <dims> notmyname : no change in status quo
21:12:39 <ttx> notmyname: just no to the resolution as it stands
21:12:40 <notmyname> thanks for the explicit clarification
21:13:00 <dhellmann> 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 <Rockyg> notmyname, so, limbo still....
21:13:03 <devananda> 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 <notmyname> Rockyg: yeah
21:13:35 <carolbarrett> devananda: if we have a set of criteria, then everyone in the community knows the rules...
21:13:35 <notmorgan> EmilienM: proposal works for me btw.
21:13:39 <ttx> ok, thanks everyone, we need to close it.
21:13:45 <annegentle> thanks ttx
21:13:46 <jroll> thanks ttx
21:13:49 <anteaya> ttx: thank you
21:13:52 <ttx> Now let's bring me that bottle of Absinth
21:13:54 <annegentle> thanks notmyname
21:14:00 <devananda> carolbarrett: exactly. I think that's what this discussion has been, in part, about
21:14:02 <ttx> #endmeeting