| *** dhellmann_ has joined #openstack-tc | 00:07 | |
| *** dhellmann has quit IRC | 00:08 | |
| *** dhellmann_ is now known as dhellmann | 00:08 | |
| *** jamesmcarthur has quit IRC | 00:26 | |
| *** jamesmcarthur has joined #openstack-tc | 01:35 | |
| *** jamesmcarthur has quit IRC | 02:12 | |
| *** jamesmcarthur has joined #openstack-tc | 02:17 | |
| *** jamesmcarthur has quit IRC | 02:21 | |
| *** jamesmcarthur has joined #openstack-tc | 02:36 | |
| *** jamesmcarthur has quit IRC | 03:02 | |
| *** slaweq has joined #openstack-tc | 04:17 | |
| *** slaweq has quit IRC | 04:22 | |
| *** slaweq has joined #openstack-tc | 05:20 | |
| *** slaweq has quit IRC | 05:24 | |
| *** evrardjp has quit IRC | 05:35 | |
| *** evrardjp has joined #openstack-tc | 05:35 | |
| *** slaweq has joined #openstack-tc | 05:35 | |
| *** slaweq has quit IRC | 05:40 | |
| *** lpetrut has joined #openstack-tc | 07:02 | |
| *** lpetrut has quit IRC | 07:03 | |
| *** lpetrut has joined #openstack-tc | 07:03 | |
| *** iurygregory has joined #openstack-tc | 07:28 | |
| *** witek has joined #openstack-tc | 07:46 | |
| *** slaweq has joined #openstack-tc | 07:53 | |
| *** jaosorior has joined #openstack-tc | 08:16 | |
| *** rpittau|afk is now known as rpittau | 08:18 | |
| *** tosky has joined #openstack-tc | 08:23 | |
| *** dmellado has quit IRC | 09:23 | |
| *** dmellado has joined #openstack-tc | 09:26 | |
| *** dmellado has quit IRC | 09:33 | |
| *** dmellado has joined #openstack-tc | 09:35 | |
| *** jaosorior has quit IRC | 09:35 | |
| *** tetsuro has joined #openstack-tc | 11:12 | |
| *** rpittau is now known as rpittau|bbl | 11:32 | |
| *** tetsuro has quit IRC | 11:50 | |
| *** Luzi has joined #openstack-tc | 11:53 | |
| *** rpittau|bbl is now known as rpittau | 13:34 | |
| *** tosky_ has joined #openstack-tc | 13:47 | |
| *** tosky has quit IRC | 13:47 | |
| *** tosky_ is now known as tosky | 13:47 | |
| openstackgerrit | Merged openstack/governance master: Add QA upstream contribution opportunity https://review.opendev.org/706637 | 14:32 |
|---|---|---|
| mnaser | tc-members: https://review.opendev.org/#/c/710020/ had a few revisions, appreciate reviews again | 14:44 |
| *** beekneemech is now known as bnemec | 15:00 | |
| *** Luzi has quit IRC | 15:01 | |
| * fungi sighs at http://lists.openstack.org/pipermail/openstack-discuss/2020-March/012928.html | 15:05 | |
| smcginnis | I was not aware of that stance by the team. This may require more discussion. | 15:08 |
| jroll | smcginnis: yeah, it's been a thing for a while :( | 15:15 |
| smcginnis | I don't like it, but it does potentially highlight a huge risk. | 15:15 |
| jroll | eg. https://docs.openstack.org/releasenotes/glance/train.html#relnotes-19-0-0-stable-train | 15:15 |
| jroll | >Documentation examples were changed from openstack commands back to glance. This should help avoid the frustration of glance-community maintaining different client than what is referred in examples. ‘python-glanceclient’ is and will be the reference implementation of Images API and the team will implement all API changes to the relevant client version of the cycle as well. | 15:16 |
| smcginnis | The OSC team is drastically understaffed at the moment. | 15:16 |
| mugsie | its been like this for a while | 15:16 |
| smcginnis | And I don't believe it is able to handle keeping up with the current needs of the projects that are part of it. | 15:16 |
| *** lpetrut has quit IRC | 15:18 | |
| jroll | yeah, that's the excuse, is that OSC devs haven't implemented everything glanceclient supports | 15:19 |
| fungi | on the other hand, projects are choosing to maintain their own separate clients rather than help | 15:19 |
| fungi | it's this siloing which is why we fail at working together as a communityty | 15:19 |
| mugsie | jroll: the main issue for a long time was the inabliity to pipe a file into OSC afaik | 15:20 |
| evrardjp | well I complained on this ... a year ago? | 15:20 |
| mugsie | evrardjp: aye | 15:20 |
| mugsie | it is a long running thing | 15:20 |
| jroll | fungi: right, that's why I said excuse instead of reason :) | 15:20 |
| evrardjp | I think the solution would have been to do the convergence of clients as a community goal, like I initially proposed | 15:20 |
| evrardjp | even if it was too ambitious... | 15:21 |
| *** jamesmcarthur has joined #openstack-tc | 15:21 | |
| smcginnis | That will take more than one cycle to do. Likely more than 5 cycles. | 15:22 |
| smcginnis | Maybe we should get something scheduled for Vancouver to have a larger discussion about this. | 15:22 |
| zaneb | evrardjp: I think I counted at least 3 goals that the Glance team has not completed since Queens | 15:24 |
| zaneb | so I'm not sure that would help | 15:24 |
| evrardjp | isn't that a big signal? :p | 15:25 |
| gmann | but what is option even big signal? | 15:25 |
| evrardjp | maybe we should have something out there to say "please help glance, they don't even have resources to support using our official common client" | 15:25 |
| zaneb | we basically did | 15:26 |
| gmann | we have been keep saying since many years | 15:26 |
| evrardjp | we said glance need help | 15:26 |
| evrardjp | I am focusing on a different point here | 15:26 |
| gmann | yeah, osc is one things but there are or may be other in future | 15:26 |
| evrardjp | I don't disagree | 15:26 |
| zaneb | and the team is fairly constrained... but if you look at their PTG output they're talking about new features to work on and not even discussing all the goals they've missed | 15:27 |
| evrardjp | zaneb: is that because other projects ask for those features? | 15:27 |
| *** jamesmcarthur has quit IRC | 15:27 | |
| zaneb | I don't remember what they were so can't comment | 15:28 |
| tosky | fungi: sorry, but sometimes project tried to help with no result (see microversion for OSC, which is blocking cinder) | 15:28 |
| tosky | fungi: please don't put all the blame on the projects | 15:28 |
| evrardjp | I mean, I have no doubt they try to be good citizens :) | 15:28 |
| *** jamesmcarthur has joined #openstack-tc | 15:28 | |
| tosky | that said, I don't agree with the full denial way that glance decided to follow | 15:28 |
| fungi | tosky: i don't, i see it as a possible sign that we might need to find ways to make it easier for them to work on osc instead of on their individual clients | 15:29 |
| evrardjp | I don't want us to be fingerpointing on who is to blame in this story | 15:29 |
| evrardjp | if possible | 15:29 |
| evrardjp | :) | 15:29 |
| evrardjp | I would rather think of a way forward | 15:29 |
| zaneb | fungi: on that note ftr I still think it's a mistake to have in-tree and out-of-tree plugins for OSC. If everything were out of tree it would be easier for all projects to develop their own | 15:30 |
| zaneb | mugsie has been trying to fix that for years | 15:30 |
| fungi | they choose not to work on osc, but that could certainly be due to friction making it too hard for them to do so | 15:30 |
| fungi | zaneb: yep, i think i agree | 15:30 |
| fungi | (but splitting my attention with a conference at the moment) | 15:31 |
| mugsie | zaneb: yeah, I stand by my plugins for all manirfesto | 15:31 |
| evrardjp | if everything was in-tree you would have a larger team | 15:31 |
| evrardjp | if everything was out of tree everything is simple | 15:31 |
| evrardjp | "simple" | 15:31 |
| tosky | evrardjp: the first part is not necessarily true | 15:31 |
| evrardjp | tosky: so is the second :p | 15:32 |
| tosky | evrardjp: the second has been proven to be at least consistent | 15:32 |
| evrardjp | it's all about side effects here | 15:32 |
| evrardjp | tosky: maybe not in the details, but in the interface indeed | 15:32 |
| evrardjp | my point is : we can talk about in-tree, out-of-tree, but it won't change the current state | 15:33 |
| zaneb | if you tell a team they can choose whether to maintain 2 clients or 1, they'll rarely choose 2 | 15:33 |
| jroll | mugsie: ++ | 15:33 |
| evrardjp | zaneb: totally agree | 15:33 |
| evrardjp | which is why I wanted to push for the story "everyone uses osc" and that's it | 15:34 |
| zaneb | if you tell a team they can maintain their own client or fight to get reviews from another team on the official client, they'll often choose to maintain their own | 15:34 |
| evrardjp | yes. | 15:34 |
| evrardjp | NIH syndrome too | 15:34 |
| tosky | evrardjp: I think that can be solved only by either a) from the OSC core team, providing the missing building blocks needed by other teams or b) giving more power to the other teams | 15:34 |
| mugsie | but - if you make them be aplugin, but not have the ability to generate cli docs - they also will think twice | 15:34 |
| zaneb | mugsie: or maybe the OSC team will think twice about their plugin support once they have no CLI docs | 15:35 |
| evrardjp | tosky: I don't disagree :) | 15:36 |
| zaneb | (relevant issue: https://bugs.launchpad.net/python-openstackclient/+bug/1735016 ) | 15:36 |
| openstack | Launchpad bug 1735016 in python-openstackclient "Plugin documentation is worthless" [Undecided,New] | 15:36 |
| zaneb | mugsie: you can at least generate them locally, they just won't appear in the OSC docs | 15:37 |
| zaneb | e.g. https://docs.openstack.org/python-heatclient/latest/cli/index.html | 15:38 |
| tosky | zaneb: uhm, about that, I didn't even know there was centralized documentation | 15:39 |
| tosky | in sahara we have had our own OSC doc for ages (from the same commands): https://docs.openstack.org/python-saharaclient/latest/cli/reference.html | 15:39 |
| zaneb | tosky: https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html | 15:40 |
| zaneb | if you are in the blessed group | 15:40 |
| *** rm_work has joined #openstack-tc | 15:41 | |
| * asettle laughs at the "plugin documentation is worthless" bug title | 15:41 | |
| asettle | Another zing, zaneb | 15:41 |
| * zaneb didn't make any friends with that one | 15:42 | |
| asettle | Shocking. | 15:42 |
| asettle | :p | 15:42 |
| evrardjp | haha | 15:42 |
| evrardjp | I am glad zaneb is not here to make friends. | 15:43 |
| evrardjp | this is serious bizniz | 15:43 |
| asettle | "However, those projects relegated to the plugin ghetto get only this word salad:" | 15:43 |
| asettle | ahahhahahahaa | 15:43 |
| zaneb | I am! I am! I plead incompetence | 15:43 |
| evrardjp | lol | 15:43 |
| asettle | Absolutely fuckin' cacklin | 15:43 |
| asettle | What a bug report | 15:43 |
| asettle | On a scale of one to 10, how annoyed were you when you wrote this? | 15:44 |
| zaneb | it was a bad day, clearly | 15:44 |
| asettle | 2017 was rough on us all man | 15:44 |
| zaneb | I can check my diary if you like | 15:44 |
| * evrardjp clicks the subscribe button | 15:44 | |
| rm_work | for the record, having been in several conversations with glance folks about this issue, it definitely doesn't seem a case of "we're trying, but there's a lot of friction and it's too difficult"... it definitely felt like "nah, didn't you hear? OSC is dead, people are supposed to just use their own plugins again" | 15:44 |
| asettle | zaneb, absolutely | 15:45 |
| evrardjp | I heard something different in the past rm_work | 15:45 |
| rm_work | I almost screamed at the guy I was talking to last time but opted to just walk away | 15:45 |
| evrardjp | that sounds a fair move that many practiced | 15:45 |
| evrardjp | :D | 15:45 |
| asettle | rm_work, interesting. It definitely was the former last time I spoke to the PTL. | 15:45 |
| rm_work | he just seemed willfully oblivious <_< | 15:45 |
| evrardjp | but I think there is a big problem, and I am trying to find a way forward | 15:45 |
| evrardjp | asettle: I got the same experience | 15:46 |
| *** jamesmcarthur has quit IRC | 15:46 | |
| evrardjp | thanks for saying this rm_work | 15:46 |
| rm_work | it also seemed very much like "well, the OSC team hasn't added all our features, so why should we use it?" | 15:46 |
| * rm_work shrugs | 15:47 | |
| smcginnis | To be fair, there are about 1.5 people actually working on glance. | 15:47 |
| rm_work | lol yes | 15:47 |
| mordred | let me know if I can help out in any way with this issue | 15:47 |
| asettle | Yeah, that's true. And has been the case for quite some time. | 15:47 |
| smcginnis | So anything that is not a quick and easy update for anything but core functionality is just not going to happen. | 15:47 |
| rm_work | but it's not like it is actually that much work to add support for projects in OSC | 15:47 |
| evrardjp | mordred: I am trying to find what are the real next steps | 15:47 |
| zaneb | oh hey, it looks like that bug was fixed and I can close it | 15:47 |
| evrardjp | because when it will be about to say "who will work on this, everyone will disappear" | 15:47 |
| evrardjp | zaneb: lol | 15:47 |
| smcginnis | "but it's not like it is actually that much work to add support for projects in OSC" < based on past experience, I have to disagree with that statement. | 15:48 |
| evrardjp | it's not a word salad anymore? | 15:48 |
| mordred | evrardjp: awesome. the landscape has changed a bit too, since we're trying to use sdk and not python-*client in OSC now | 15:48 |
| evrardjp | that's true | 15:48 |
| mordred | so where in the past one of the reasons for being minimal in OSC core was due to library proliferation hell | 15:48 |
| mordred | the situation on the ground is markedly different now | 15:48 |
| rm_work | Octavia added support. the hard work was actually adding SDK support, but we didn't have to go that route IIRC | 15:48 |
| mordred | so maybe we shoudl all circle back around and figure out what we can do differently | 15:48 |
| evrardjp | mordred: which is why I think it's now question on what are the next steps | 15:48 |
| mordred | yup | 15:48 |
| rm_work | so has that changed, and SDK is now mandatory? | 15:48 |
| smcginnis | mordred: ++ | 15:49 |
| evrardjp | mordred: that does sound like a community goal we had pushed forward with lbragstad and I, one or two years ago :p | 15:49 |
| mordred | rm_work: it's not mandatory - but it IS the direction we're trying to head - because otherwise installing a working OSC winds up installing a hundred bazillion packages - when all that it's doing is making REST calls | 15:49 |
| * evrardjp gets old | 15:49 | |
| mordred | evrardjp: :) | 15:49 |
| mordred | evrardjp: the longer you're around the more everything comes back | 15:49 |
| evrardjp | You know what you're talking about :p | 15:50 |
| mordred | I wouldn't go that far ) | 15:50 |
| mordred | :) | 15:50 |
| evrardjp | so the next logical step -- for the folks wanting to help glance -- is to make sure that everything that the glanceclient is doing is integrated into sdk, correct? | 15:52 |
| zaneb | ah, they moved to storyboard and then fixed it: https://storyboard.openstack.org/#!/story/1735016 | 15:52 |
| rm_work | part of me wants to just go freaking implement whatever is actually missing | 15:52 |
| evrardjp | rm_work: yeah, well, establish a delta, and getting it done? | 15:53 |
| rm_work | but another part of me feels like that team doesn't deserve to go the shitty route and have a bunch of other folks do the work for them <_< | 15:53 |
| rm_work | but yep, at least establishing a delta should be doable | 15:53 |
| rm_work | though I worry about hidden bits that aren't obvious where functionality might be broken even though everything looks the same as far as keywords/args | 15:54 |
| rm_work | re: the start of that whole email thread | 15:54 |
| rm_work | though it turns out it's broken the same in both clients, so eh :D | 15:54 |
| *** lpetrut has joined #openstack-tc | 15:55 | |
| rm_work | my suggestion to them in the past was, continue recommending the use of OSC, and report bugs as they come up, and get them fixed! which apparently was too onerous | 15:56 |
| rm_work | because it seems like most of the actually important functionality is there... we don't use anything but OSC for management of images in our cloud and have never had issues | 15:56 |
| rm_work | it's not like the glance API has actually changed in like 3 years | 15:56 |
| mordred | as I mentioned in the thread too, gtema has a patch up for migrating osc from glanceclient to sdk | 15:57 |
| rm_work | so step 1 might be to review/merge that | 15:57 |
| mordred | which will get things like support for clouds that require uploading to switch first and whatnot | 15:57 |
| rm_work | to get us moving in the right direction | 15:57 |
| mordred | ++ | 15:57 |
| *** dmellado has quit IRC | 15:57 | |
| mordred | s/switch/swift/ | 15:57 |
| evrardjp | yeah that sounds awesome | 15:58 |
| evrardjp | mordred: are there other places where osc is not using the sdk still? | 15:59 |
| evrardjp | Sorry I am not aware of the lay of the land | 15:59 |
| *** dmellado has joined #openstack-tc | 16:00 | |
| tosky | evrardjp: sahara for sure (as it switched to osc long ago) | 16:00 |
| mordred | evrardjp: many - it's still mostly using *client - but we're finally at the point where we're comfortable making teh switch. glanceclient-ectomy was the first switch of existing *client usage | 16:00 |
| mordred | https://review.opendev.org/#/c/699416/ fwiw | 16:01 |
| rm_work | cool, will look | 16:03 |
| rm_work | yeah Octavia just did its initial OSC work via SDK I believe... | 16:03 |
| * rm_work double checks | 16:03 | |
| *** jamesmcarthur has joined #openstack-tc | 16:04 | |
| *** jamesmcarthur has quit IRC | 16:04 | |
| *** jamesmcarthur has joined #openstack-tc | 16:05 | |
| rm_work | hmm apparently I'm wrong :D | 16:05 |
| rm_work | so, probably we're due for switching to SDK -- I can probably look at that, we're used to being a guinea pig / canary :) | 16:06 |
| evrardjp | haha | 16:06 |
| mugsie | designate is the same, we migrated before SKD was really a thing | 16:06 |
| mugsie | SDK* | 16:06 |
| *** lpetrut has quit IRC | 16:06 | |
| evrardjp | this isn't a coal mine, you won't die from this. | 16:06 |
| mordred | wait. I'm not supposed to be sitting in a coal mine when I work on openstack? | 16:07 |
| * mugsie narrator voice: this was a foreshadowing moment | 16:07 | |
| evrardjp | hahah | 16:07 |
| evrardjp | mordred: you didn't see my previous workplace apparently. | 16:07 |
| evrardjp | oh also, I am a mining engineer by formation. | 16:08 |
| evrardjp | I totally see you in a mine mordred. | 16:08 |
| rm_work | I mean, Octavia has two mascots, after all... | 16:08 |
| rm_work | https://usercontent.irccloud-cdn.com/file/C1rMwjI7/IMG_20200303_010838.jpg | 16:09 |
| clarkb | re osc, I wonder if some of the disconnect here is that osc has startup overhead that the *clients don't have due to lack of plugin loading in those specific clients. | 16:10 |
| clarkb | definitely the biggest issue using osc today as a user is its slowness | 16:10 |
| clarkb | (just about everything else about it is great though) | 16:11 |
| rm_work | slow as in ... because it has to make like 4 calls to get going (auth, service-catalog, etc) before making the actual call you meant to do? :D | 16:12 |
| fungi | plugin entrypoint discovery via pkg_resources i think? | 16:13 |
| rm_work | ah, that kind of slow | 16:13 |
| clarkb | rm_work: that is part of it, and reusing tokens does dramatically improve performance too. But the other part of it is the plugin entrypoint loading by pkg_resources | 16:13 |
| fungi | when you're calling osc over and over not in its persistent interactive mode | 16:13 |
| fungi | (read: you're using devstack) | 16:14 |
| clarkb | it has to scan all location in your PYTHONPATH, then list package details for every package found then it sorts every package. This means it gets slower if you have more packages installed and if you have slow disk | 16:14 |
| evrardjp | clarkb: didn't you write a bug and/or propose a fix for that? | 16:14 |
| rm_work | fungi: or you're running a bunch of scripts in CI/CD that just calls `openstack <blah>` a ton :D | 16:14 |
| clarkb | the *clients have the same token+catalog overhead but no the entrypoint slowness | 16:14 |
| evrardjp | I remember you proposing an alternative | 16:14 |
| fungi | rm_work: yup | 16:14 |
| rm_work | (which is what we do) | 16:14 |
| evrardjp | or maybe I am wrong? | 16:14 |
| clarkb | evrardjp: its actually slower in the python2 case and only marginally faster in the python3 case | 16:14 |
| evrardjp | rm_work: that's what everyone does | 16:15 |
| evrardjp | :p | 16:15 |
| clarkb | evrardjp: the updated python lib to load entrypoints uses the same underlying algorithm, they just do it a bit more efficiently | 16:15 |
| clarkb | *more efficiently on python3 | 16:15 |
| clarkb | the real fix imo is to stop loading entrypoints at all | 16:15 |
| fungi | but the slowdown is still geometric with the number of modules installed | 16:15 |
| clarkb | fungi: yes | 16:15 |
| evrardjp | fungi: ofc | 16:15 |
| fungi | even with the new implementation | 16:15 |
| clarkb | we might also want to look at caching tokens again | 16:16 |
| clarkb | because that does have a big impact too | 16:16 |
| mordred | that's one of the reasons we don't do any entrypoint plugins in sdk - the cost. I think unwinding that completely from osc would be a _large_ effort, but one we could certainly talk about in the new sdk world. probably a good topic for the PTG | 16:17 |
| *** dmellado has quit IRC | 16:18 | |
| *** dmellado has joined #openstack-tc | 16:20 | |
| *** witek has quit IRC | 16:23 | |
| clarkb | mordred: one idea I had was to stop using entrypoints for the in tree commands at least | 16:25 |
| mordred | yeah - I thought some work had happened in that direction | 16:25 |
| clarkb | but I think you'd have to do 90% of the work to untangle those from the plugin system as you would to stop using entrypoints for plugins alltogether | 16:26 |
| clarkb | (so not easy or quick fix) | 16:26 |
| mordred | yeah | 16:26 |
| mordred | clarkb: I thought there was some work in stevedore that was done to allow an optimized path for things like the in-tree plugins ... but maybe that effort just didn't get finished | 16:26 |
| mordred | I think we should _definitely_ have a session on this topic at the PTG - although we obviously don't have to wait until then to work on things - but it seems like figuring out blockers, plans and pain points would be useful to everyone | 16:28 |
| rm_work | is someone planning to do the necessary rebasing on that glance->SDK patch? | 16:28 |
| mordred | rm_work: gtema is on PTO - so if we want to move it forward before he's back someone else should probably step in | 16:30 |
| rm_work | i'll take a crack at it really quick | 16:32 |
| mordred | rm_work: cool, thanks! | 16:34 |
| *** diablo_rojo has quit IRC | 16:40 | |
| *** diablo_rojo has joined #openstack-tc | 16:40 | |
| *** dmellado has quit IRC | 16:46 | |
| *** dmellado has joined #openstack-tc | 16:49 | |
| *** rpittau is now known as rpittau|afk | 16:59 | |
| *** dmellado has quit IRC | 17:01 | |
| fungi | tim says we should make it a cycle goal. who am i to argue with tim? | 17:06 |
| mordred | fungi: yeah. tim is one of the main reasons I've been pushing on this... if it'll make tim happy, that seems like the best motivation | 17:07 |
| *** dmellado has joined #openstack-tc | 17:07 | |
| evrardjp | :) | 17:10 |
| rm_work | cycle goal for OSC support seems good to me, FWIW :D | 17:11 |
| evrardjp | \o/ | 17:11 |
| evrardjp | history truly repeats itself! | 17:11 |
| evrardjp | haha | 17:11 |
| *** dmellado has quit IRC | 17:19 | |
| *** dmellado has joined #openstack-tc | 17:25 | |
| rm_work | waiting on local pep8 and this rebase is done | 17:26 |
| mordred | rm_work: sweet | 17:27 |
| *** evrardjp has quit IRC | 17:35 | |
| *** evrardjp has joined #openstack-tc | 17:35 | |
| rm_work | done, posted. not too bad. | 17:40 |
| rm_work | I think it maybe needed more work than just a rebase though? | 17:43 |
| rm_work | will take a look after tests run | 17:43 |
| *** iurygregory has quit IRC | 18:19 | |
| *** KeithMnemonic has joined #openstack-tc | 18:35 | |
| dhellmann | mordred , clarkb , rm_work, evrardjp : dtroyer and I came up with a plan to make in-tree plugins static in OSC, but I never had time to build it in part because the details were a bit more complicated than I thought. | 19:33 |
| dhellmann | My initial idea was to just have a table built into the code for well-known commands and fall back to the plugin scan if something wasn't found. | 19:33 |
| dhellmann | Because of the multi-layer loading to handle API versioning, that proved more challenging to actually implement than I thought it would be. | 19:34 |
| mordred | dhellmann: ah - ok, so at least I wasn't imagining you having worked on it at least | 19:34 |
| mordred | at least | 19:34 |
| mordred | not sure why I said at least twice | 19:34 |
| mordred | but a third seemed like a worthy addition | 19:34 |
| dhellmann | I suggest looking into dropping the use of plugins entirely, and just build the argparse command tree you'd need. Although that's going to have the same problem, that some options are only available when some API versions are in use. | 19:35 |
| dhellmann | So maybe dropping that behavior would make the other work easier. | 19:35 |
| mordred | yeah. it might be that we need to register all of the argparse commands regardless of whether they'd work | 19:35 |
| dhellmann | it's not even the commands, it some options to some commands | 19:36 |
| mordred | and do later validation | 19:36 |
| mordred | yeah | 19:36 |
| mordred | argparse things :) | 19:36 |
| dhellmann | you get a different version of the "noun verb" level plugin based on API version | 19:36 |
| mordred | yeah | 19:36 |
| dhellmann | although if I had my druthers, I'd say force everyone to go do the work in gopherlib and build a go client because that's going to result in better API design over the long term. We have way too many APIs that are "put a bunch of JSON here, good luck figuring out what it should hold" | 19:37 |
| dhellmann | that's unlikely to be a widely popular opinion, though :-) | 19:37 |
| mordred | yeah - many other dragons there :) | 19:37 |
| mordred | but - I think we've got a good basis for dealing with teh API in sdk - and in sdk we actually present the same interface all the time no matter what the remote api version is | 19:38 |
| mordred | so maybe as part of sdk-ificiation we can remove the osc behavior of presenting version-dependent options | 19:38 |
| mordred | that will probably be more compicated than just saying it though | 19:38 |
| dhellmann | probably, yeah | 19:39 |
| mordred | dhellmann: thanks though - that's super helpful in terms of knowing areas that have been investigated and areas to go poke at | 19:39 |
| dhellmann | there's an etherpad from the last PTG in Denver somewhere with maybe more details | 19:39 |
| *** jamesmcarthur has quit IRC | 19:40 | |
| mordred | awesome | 19:40 |
| *** jamesmcarthur has joined #openstack-tc | 19:40 | |
| *** jamesmcarthur has quit IRC | 19:45 | |
| mnaser | i think it's time to seriously consider moving away from the PTL model | 20:00 |
| mnaser | i've discussed with a few people the idea of actually having something like "maintainers" | 20:00 |
| mnaser | which could be nothing other than the actual core reviewers for example | 20:01 |
| mnaser | and that way, the responsibility of the project and the tasks of being a PTL is delegated between multiple people | 20:01 |
| mnaser | and then leave it up to the teams to split work between them | 20:02 |
| mnaser | esp with nova in the state it is in, and that no one really wants to volunteer to PTL afaik. | 20:02 |
| smcginnis | Diffusion of responsibility is a much larger risk than the ability of a PTL to delegate responsibilities. | 20:05 |
| cmurphy | mnaser: my worry would be that we lose accountability among the maintainers, everyone will think that someone else will take care of X | 20:05 |
| fungi | also core reviewership is currently conferred from the ptl, a prerequisite would be to determine how maintainers/core reviewers are identified by an established chain of governance | 20:06 |
| mnaser | smcginnis, cmurphy: i think both of you have a point here, but it seems like teams generally share that responsibility between them from what i've noticed | 20:06 |
| clarkb | fungi: re that I've often wondered if we should have more formal openstack maintainer type roles. Basically epople that do the work that sdague and mtreinish and mriedem and jogo were doing when they worked on openstack | 20:06 |
| mnaser | the way i'd imagine it is something inside the meeting "hey did anyone get the email about X?" "ok, Y will take an action item of taking care of it" | 20:06 |
| fungi | from a governance perspective, the osf bod identifies an elected body of tc members to govern official projects, and the tc in turn identifies ptls (normally by proxy from holding elections for those seats), then the ptls identify core reviewers and other delegations as they see fit | 20:07 |
| clarkb | then maybe we aren't competing among projects for resources but can pool them together. But similarly would need updates to how responsibility is conferred | 20:07 |
| fungi | what i describe is the current model, to be clear | 20:08 |
| njohnston_ | I think this might work ok for larger teams - along the lines of how the liaison system effectively sharded some of the PTL's communication and representation responsibilities - but I don't know that it would help much for medium to small projects. | 20:08 |
| mnaser | medium to small projects can have one 'maintainer' | 20:08 |
| mnaser | that's something that the team can sort out between them together in a way | 20:08 |
| fungi | governance-wise there still needs to be some form of delegation from the tc to the people responsible for each project (whether they're ptls or maintainer groups) | 20:09 |
| mnaser | there hasn't been much times that i've needed (as tc) to reach out to "the ptl" and usually reaching out to the team helps | 20:10 |
| mordred | fungi: I disagree with your description. the osf bod does not identify an elected body of tc members. the osf bylaws define the exist of both a board of directors and a tc who have various electorates | 20:10 |
| fungi | mordred: yes, your description is more accurate | 20:11 |
| mnaser | "Project Team Leads (“PTLs”) manage day-to-day operations, drive the team goals and resolve technical disputes within their team. Each team should be self-managing by the contributors, and all disputes should be resolved through active debate and discussion by the community itself. However if a given debate cannot be clearly resolved, the PTL can decide the outcome. Although the TC is generally not involved in | 20:11 |
| mnaser | team-internal decisions, it still has oversight over team decisions, especially when they affect other teams or go contrary to general OpenStack goals." | 20:11 |
| fungi | mordred: and hidden therein is also the fact that the relevant sections of the bylaws require agreement of the tc to change them | 20:11 |
| mordred | fungi: that said - I believe the PTLs and team structure does derive from the TC delegation - so I think your overall point is solid | 20:12 |
| mordred | fungi: yup | 20:12 |
| mnaser | i really think that stuff can just be delegated a layer down to the team (based on what it's defined right now). it's not like the tc is running after ptls about releases, or about hitting freeze targets, etc | 20:12 |
| mordred | fungi: it is one of the reasons TC is a very unfortunate name | 20:12 |
| fungi | mnaser: what's still missing there is who says who's on those maintainer teams? presumably the tc, or the tc defines some mechanism through which that choice is proxied | 20:13 |
| fungi | since the tc is ultimately still responsible for them | 20:13 |
| fungi | if that decision is proxied, the proxy needs definiting | 20:13 |
| fungi | er, defining | 20:13 |
| mnaser | fungi: yep, agreed. | 20:13 |
| fungi | the current proxy is contributor elections in each team to pick a ptl | 20:14 |
| fungi | so that's the challenging bit to define, i think | 20:14 |
| mnaser | perhaps a ptl can just become a 'maintainer' or maybe a 'project owner' -- which we can have multiple of | 20:16 |
| fungi | the "can become" part is what i'm saying is the challenge. how does someone "become" a maintainer, formally? | 20:17 |
| mnaser | yeah, i don't know about that part yet | 20:18 |
| fungi | we can't punt and say "it's just the core reviewer model" because 1. officially ptls are the folks who say who can be a core reviewer right now, and 2. not all teams have the same sorts of core reviewer sets | 20:18 |
| mnaser | but thoughts and ideas are welcome | 20:18 |
| njohnston_ | fungi: The only way I can think of is for maintainer status to be something nominated and elected from within the project's contributor base | 20:18 |
| fungi | njohnston_: that's far from the only way i can imagine, but it's certainly one which would be familiar relative to the current model | 20:19 |
| mnaser | anyone familiar with some of the k8s governance and perhaps how they deal with this? | 20:20 |
| njohnston_ | fungi: Fron a practical perspective with a contributor base that is used to having a say in their project management through elections, any method that does not use elections would come across as disempowering | 20:20 |
| mnaser | njohnston_: does it though? if i dont merge any of your patches in a cycle, you technically cant have a say :-P | 20:20 |
| fungi | also a core reviewer can stack the current ptl electorate with folks who are likely to vote for a specific candidate by approving changes from them | 20:21 |
| fungi | but i think either of those are pathological malfunction of the team structure which ultimately should be escalated to the tc for resolution | 20:22 |
| njohnston_ | Agreed. And hopefully diversity of core contributors would help protect against that in most cases | 20:23 |
| fungi | i think some of the subtext here is also what happens if nobody volunteers to lead the nova team now that efried has announced his departure. is nova "too big to fail"? or will the project continue running just fine without any formal leadership? or does the tc need to find a new model which empowers the nova team when nobody wants ultimate ptl responsibilities? | 20:24 |
| dansmith | #2 please | 20:24 |
| dansmith | well, | 20:24 |
| njohnston_ | I think this would have some traction if it was phrased as “instead of one PTL, many PTLs” | 20:25 |
| dansmith | #1 is fine too, but it sounds like that can't happen because of so much boilerplate | 20:25 |
| fungi | currently, #2 means it continues sailing along as no longer part of openstack because there's no delegation from the tc to the folks running the project | 20:25 |
| njohnston_ | fungi: and is there something about the nova PTL position that is uniquely difficult? | 20:25 |
| fungi | njohnston_: i'm not, nor have i every been, ptl of nova so i'm unable to answer your question with any authority | 20:26 |
| mnaser | i've seen the nova team consistently share responsibilities with things like running PTGs, project updates, etc | 20:26 |
| dansmith | fungi: just to put you on the spot... do you really see nova being excluded from openstack because of something like this? | 20:28 |
| dansmith | I mean, not to put too much special sauce on nova, but I would think that nova not being part of openstack would be an outcome that doesn't benefit anyone, really | 20:28 |
| fungi | dansmith: that was my "too big to fail" allusion. i don't see any outcome where nova is no longer formally part of openstack as a successful result | 20:28 |
| dansmith | fungi: well, you said #2 would imply nova not being openstack | 20:29 |
| fungi | yep. consider it included as completeness | 20:29 |
| * dansmith doesn't get it | 20:30 | |
| dansmith | but that's okay | 20:30 |
| fungi | another way to phrase this would be we need to find a governance model which formally delegates the running of the project from the bylaws and tc | 20:30 |
| mnaser | i think dansmith is trying to mostly find the leastway with the least amount of friction so he can focus on getting stuff done without having to worry about juggling "who's gonna wear the PTL hat" | 20:30 |
| fungi | one option might be that the tc collectively takes on pt duties for nova, because the tc is ultimately responsible for it | 20:31 |
| fungi | (to be honest i also don't see that as being a great option) | 20:31 |
| dansmith | mnaser: yeah, we're kinda out of people to spend a bunch of time doing that kind of stuff, IMHO | 20:31 |
| fungi | "that stuff" being facilitating ptg discussions, tracking completion for cycle goals, proposing releases... | 20:32 |
| fungi | are those things nova is deciding are irrelevant? | 20:32 |
| mnaser | fungi: i think that's a two part answer | 20:32 |
| mnaser | first -- those aren't documented PTL roles "technically" | 20:33 |
| fungi | (the folks working on nova collectively that is. it's hard to say what "nova decides" when it's no longer a euphemism for what "nova's elected ptl decides") | 20:33 |
| mnaser | we historically say they are but the governance docs dont really say much about that | 20:33 |
| fungi | yeah, i'm curious what people think they're responsible for by volunteering to be a ptl (or a maintainer, or whatever replaces the ptl) | 20:34 |
| njohnston_ | does nova have a team that is “the core of the cores” analogous to the neutron drivers team? | 20:34 |
| mnaser | and secondly, personally i've seen that responsibility mostly shared across teams, which is something to decide between them | 20:34 |
| dansmith | njohnston_: we used to, but it basically died and was squashed in because it "wasn't fair" | 20:34 |
| njohnston_ | ah ok | 20:34 |
| fungi | mnaser: the tc currently expects ptls will find someone to do those things though, right? | 20:36 |
| mnaser | in my experience, that isn't what ends up happening :( | 20:36 |
| mnaser | or at least, most of the smaller teams | 20:36 |
| mnaser | i think if we focus on empowering teams so they can organize themselves on who wants/can deal with what | 20:36 |
| mnaser | it'll be easier for us and them | 20:37 |
| fungi | hypothetical, nova decides it's going to ignore a cycle goal... i won't make up a specific example it's a thought exercise... what's the solution? and say it's not nova but... glance. is the solution the same? | 20:37 |
| fungi | or should we reframe how we look at cycle goals? | 20:39 |
| njohnston_ | if we decide to move to a maintainer system, do we just move the problem down the stack? i.e. cores a, b, and c don't want to be PTL because they don't want to do the summit project update or organize the PTG discussions. So we make them a maintainer team, and then they do all the PTL stuff except noone does the project update or organize PTL discussions? | 20:39 |
| clarkb | njohnston_: thats sort of why I wonder if global maintainers makes more sense | 20:39 |
| fungi | keeping i mind that ptl attendance and project updates are entirely optional | 20:39 |
| clarkb | njohnston_: empower people interested in the work (assuming they exist) to do it for more than a single silo | 20:40 |
| fungi | er, ptg attendance | 20:40 |
| dansmith | njohnston_: fwiw, we often have non-PTL people doing or participating in the project update, and organizing ptg discussions.. that's never really been a struggle | 20:40 |
| mnaser | its not like we can do much about it *even* if the project has a ptl | 20:40 |
| mnaser | (wrt cycle goals) | 20:40 |
| fungi | right. is there anything we actually hold a ptl accountable for, as a community, other than formally delegating the list of people allowed to merge changes in the project they represent? | 20:41 |
| mnaser | https://governance.openstack.org/tc/reference/charter.html#project-team-leads | 20:41 |
| mnaser | i dont think we even formally delegate the list of people allowed to merge changes :p | 20:41 |
| mnaser | if anything ... "Each team should be self-managing by the contributors" | 20:42 |
| fungi | yep, good point | 20:42 |
| dansmith | btw, are you people mostly worried about the "now until the next election" period, or the next election having no candidated? | 20:43 |
| dansmith | s/d// | 20:43 |
| mnaser | dansmith: for me personally, both | 20:43 |
| fungi | that would also fall into resolving disagreements. the ptl is delegating the ability to assess agreement on when a change is suitable to merge | 20:43 |
| mnaser | i'm pretty sure nova might not be the only ptl-less project come next elections | 20:43 |
| dansmith | if not then it seems like redefinition might be worthwhile | 20:44 |
| njohnston_ | We have functional documentation - https://docs.openstack.org/project-team-guide/ptl.html - that basically resolves down to "make sure the right people are cores, the right people are liaisons, the right people are managing releases, the right people are doing project updates/forum sessions, and look at the user survey" | 20:45 |
| mnaser | i wonder if it might make sense for maintainers to be people that are not necessarily core members | 20:46 |
| dansmith | I dunno if it's really unclear, or more specifically a nova thing, or people are just papering over it, | 20:46 |
| mnaser | because someone might be interested to contribute... but in helping coordinate releases only, or runining project updates | 20:46 |
| evrardjp | mnaser: this is very close to what I discussed with you in the past I see. I intended to write that down in the ideas repo, but maybe you can go ahead and draft it? | 20:46 |
| mnaser | if i'm drafting this it's going straight to openstack/governance :p | 20:46 |
| dansmith | but being the PTL does bring a lot of focus from everyone who wants their feature to be merged, or blessed, or someone to appeal those things not happening, etc | 20:47 |
| dansmith | perhaps that's just something we have to figure out how to break out of while retaining the single point person that the rules require, I dunno | 20:47 |
| mnaser | i get the feeling that being nova's ptl is a lot more than other projects | 20:47 |
| fungi | say i'm coming to this new (and it's a question i hear from people at companies who are assessing whether they should risk getting involved in a project)... who decides whether my proposed changes will be merged, how do i know their decision will be impartial, and who do i escalate my concerns to if i discover they aren't? | 20:48 |
| dansmith | but I don't think that you guys convincing yourselves that the rules don't actually require someone to do "that much work" is going to change anything :) | 20:48 |
| mnaser | fwiw https://etherpad.openstack.org/p/tc-train-ptg L174 | 20:48 |
| mnaser | but it looks like none of that really ended up helping the idea of leaderless projects | 20:49 |
| mnaser | but instead just focused on "this isn't that big of a deal and its not a long of work" | 20:49 |
| fungi | dansmith: i believe the ptls of nova have done a vast amount of necessary work. what i question is whether getting rid of the ptl means that work no longer needs to get done | 20:49 |
| njohnston_ | dansmith: Right, ifyou aren't doing the work then you're spending a bunch of time coordinating (at best) or hounding (at worst) other people to get the work done. Non-trivial investment of capacity is going to happen one way or another. | 20:49 |
| mnaser | i actually think the factor of "its not my problem" helps resolve the overload of stuff the ptl needs to deal with | 20:50 |
| dansmith | fungi: not saying it doesn't all need to get done (some definitely doesn't) but being the focal point for that is not great | 20:50 |
| fungi | does replacing the ptl with a group of people solve the pressure by turning it into a shell game where nobody can figure out who to pressure to merge their change? | 20:50 |
| mnaser | a ptl saying "its not my problem" is "a bad ptl" (im putting quotes here because that might be the general thought), a maintainer saying "its not my problem" isn't an issue, just find another one | 20:50 |
| evrardjp | mnaser: if it's embryonic there is no reason to have it in governance. If it's ready go ahead. | 20:50 |
| mnaser | if you cant convince a single maintainer | 20:50 |
| dansmith | fungi: do you think people should be pressured to merge changes? | 20:50 |
| mnaser | it probably doesn't make sense to push | 20:50 |
| * evrardjp continue catching up | 20:50 | |
| fungi | dansmith: i don't think people should be pressured to merge changes. maybe the solution to that problem isn't getting rid of the ptl | 20:51 |
| dansmith | fungi: I don't really think we need to have a supreme court of final appeal to get something merged | 20:51 |
| mnaser | i think at the end of the day, people *will* go to the ptl, and the fact it's one single individual, it all ends up on their plate | 20:52 |
| dansmith | fungi: well, you seem to keep reverting back to "who do I have to pay to get this merged?" kinda thing | 20:52 |
| dansmith | yup | 20:52 |
| fungi | maybe it should be the tc's responsibility to tell contributors to shut up and stop pestering the nova ptl to contest merging a change | 20:52 |
| dansmith | not only that, | 20:52 |
| fungi | dansmith: i come back to it because it seems to be the crux of the pain | 20:52 |
| dansmith | but entities involved, people and companies, kinda expect the PTL to be the last buck on policies and responsibility for those that get selected | 20:52 |
| mnaser | i think it's that but also some other misc stuff that you seem to sign yourself up without agreeing to | 20:53 |
| fungi | just because i acknowledge that's some of what makes the role painful doesn't mean i think it's a good thing, but it might still be a reality | 20:53 |
| mnaser | aka "can somoene take care of the project update?" vs "well no one is volunteering for a project update and i'm the ptl so.." | 20:53 |
| mnaser | feels like it'll kinda force a bit more cooperation across people somehow. | 20:53 |
| mnaser | i think there's *a lot* of relief to be done if there was more than one name on that list | 20:54 |
| fungi | dansmith: but to pick that pain point, does it magically go away if there's no ptl? or do the folks applying that pressure find someone else to be the focus of their pestering? | 20:54 |
| mnaser | yes, they can try and ping different cores, and cores can say "sorry, not interested" | 20:54 |
| dansmith | no, it doesn't go away, but it becomes more of a "find someone who cares about this, because I do not" sort of thing | 20:55 |
| dansmith | which I think is easier to deal with | 20:55 |
| dansmith | obviously the PTL could take a hard line on that | 20:55 |
| mnaser | but no PTL ever does | 20:55 |
| dansmith | but you know.. it'd be difficult | 20:55 |
| dansmith | mnaser: right | 20:55 |
| mnaser | and even if they did, they'd go to another core | 20:55 |
| mnaser | which would come back to the PTL | 20:55 |
| dansmith | I'm like the most negative person on the project... I can say no to anything.. and it gets really exhausting | 20:57 |
| mnaser | dansmith: i'm glad you said yes to not running an UPDATE on all instance rows in train upgrades then \o | 20:57 |
| mnaser | \o/ | 20:57 |
| dansmith | heh | 20:57 |
| evrardjp | dansmith: and? How is that linked to governance? | 20:58 |
| evrardjp | sorry but I fail to see the big picture, it sounds like team organisation | 20:58 |
| fungi | dansmith: no, that's great. i'd rather hear form the person with the strongest opinions on why something doesn't work than the most amenable/apathetic one | 20:58 |
| dansmith | evrardjp: it's not | 20:58 |
| mnaser | i agree that it's not team organization :\ | 20:58 |
| evrardjp | but I understand some roles are tedious, and we should help make them less tedious | 20:58 |
| fungi | so to try to summarize, the impetus to no longer elect a ptl for nova is because nobody wants to be the focus of pressure for everyone who wants their fixes/features merged, and nova should be able to assess team consensus collectively without a fallback to resolve disputes | 20:59 |
| *** jamesmcarthur has joined #openstack-tc | 20:59 | |
| dansmith | fungi: I'm not really that person either.. I'm not demanding some other plan be in place, I'm just in here chatting with you people.. I think the fact that we need an interim ptl for a short period of time and nobody is willing to step up is just a symptom worth noting | 20:59 |
| * mnaser suggests that every TC member at least sits in Nova PTG for a couple hours at least | 20:59 | |
| evrardjp | dansmith: that we can probably all agree on :) | 20:59 |
| dansmith | fungi: no dude, I'm saying that's one reason I think nobody wants to do it.. please don't take my words as speaking for the whole team | 21:00 |
| fungi | dansmith: until you mentioned it, i hadn't considered that pressure from prospective contributors to deny changes was the biggest pain point for a nova ptl | 21:00 |
| mnaser | i think everyone would have a lot more perspective being on those | 21:00 |
| dansmith | I don't even know that it's the biggest, it's just one | 21:00 |
| fungi | but it's one you've heard, from within the team | 21:00 |
| mnaser | some of the suggestions that come in are so far developed and you have to sit and say "what you're doing doesn't add up" | 21:00 |
| mnaser | and people having pressure from their organizations to deliver on the features inside upstream | 21:01 |
| *** njohnston_ is now known as njohnston | 21:02 | |
| fungi | probably this is a discussion which should happen on the ml | 21:07 |
| fungi | to get broader input | 21:07 |
| mnaser | yep | 21:08 |
| mnaser | i just like to start in IRC to get a small idea first | 21:08 |
| evrardjp | that's basically what I proposed above :p | 21:08 |
| dansmith | fungi: if/when you do, please don't say "dansmith said $thing was a/the/etc problem" | 21:08 |
| fungi | dansmith: no, no, we should *restart* the discussion on the ml is what i really meant ;) | 21:09 |
| dansmith | I think you took and ran with that one thing I brought up as a not-just-the-documented-responsibilities example and turned it into the or one of the most important things, and it's really not, it's just part of it.. and an example | 21:09 |
| dansmith | k | 21:09 |
| evrardjp | dansmith: tbh, I would expect you to chime in on the thread :p | 21:09 |
| dansmith | evrardjp: you might not want to hold your breath :) | 21:09 |
| fungi | i wouldn't want to put words in anyone's mouth, if you want to raise opinions on the ml thread that's for you to do | 21:09 |
| evrardjp | :) | 21:10 |
| fungi | dansmith: though i do hope someone's still around in nova to explain what ptl responsibilities specifically discourage them from offering to be ptl | 21:10 |
| dansmith | fungi: well, I'm sure you can imagine that all the people sitting around not volunteering for it are doing so with reasons and not lack thereof :) | 21:11 |
| * ttx waves from his vacation spot | 21:11 | |
| mnaser | lolol | 21:12 |
| mnaser | i was just thinking of ttx missing all this :) | 21:12 |
| fungi | yep, and i want to learn what those reasons are, so the community can evaluate ways to possibly find solutions to those reasons | 21:12 |
| ttx | mnaser: come on, you raised it now by design | 21:12 |
| ttx | but I see everything | 21:12 |
| mnaser | ttx: you're *welcome* | 21:13 |
| mnaser | would you have preferred on your way back from vacation instead? | 21:13 |
| ttx | re: no more PTLs, the two main issues qare: | 21:13 |
| ttx | what happens if core reviewers disagree ? Do we default to doing nothing? | 21:13 |
| ttx | and how do we get critical functions filled, like release liaison (release signoff) ? | 21:13 |
| ttx | internet connection spotty here | 21:14 |
| ttx | So ideally we'd keep the "bucket stops here" function but remove the expectation that this is the person to ping to police core reviewers and get review priority | 21:15 |
| ttx | I mean, we could say that the TC arbitrates disputes between core reviewers... | 21:16 |
| ttx | but I'm not sure that's actually desirable | 21:16 |
| fungi | i'd be interested to hear ideas on how to convince folks that they shouldn't pester the ptl to get changes reviewed | 21:17 |
| ttx | maybe remove the PTL "core police" function | 21:17 |
| fungi | that doesn't seem like something we tell people to do in the first place | 21:17 |
| mnaser | ttx: i feel like at our current velocity i doubt we're moving things so quickly that someone is very unhappy about fixing disagreements | 21:17 |
| mnaser | man i cant write today, jetlag hitting hard | 21:17 |
| ttx | mnaser: used to be that project teams were pretty strongly against TC getting into their affairs... maybe times have changed | 21:18 |
| mnaser | what i mean is i dont think PTLs are doing a lot of "clearing out disagreements" and maybe that can just be escalate to the TC *at the very worst* | 21:18 |
| mnaser | i dont think PTLs enjoy being a tiebreaker either. | 21:18 |
| mnaser | maybe rather than the TC *getting* into their affairs, we can help facilitate the conversation if there are two strong opinions/sides | 21:19 |
| ttx | mnaser: frankly I think there is more promise in decoupling teams from review core areas | 21:19 |
| ttx | mnaser: your other suggestion | 21:19 |
| mnaser | personally during the whole placement thing, i really found it useful to just sit with everyone and be like "ok cool, lets come up with a plan" | 21:19 |
| mnaser | i think it took like 10-15 minutes to come up to something that everyone agreed to and jot it down | 21:19 |
| ttx | anyway, I'm not around this week, so feel free to burn everything down | 21:20 |
| ttx | I might get snowed in anyway | 21:21 |
| fungi | ttx: so get rid of per-project core review teams in favor of openstack-wide maintainer teams? | 21:22 |
| ttx | fungi: no, have teams around functional domains and core reviews around sections of code | 21:22 |
| fungi | though you should really get back to vacationing and reply another time ;) | 21:22 |
| * fungi needs to get back to being at a conference and not ignoring it | 21:23 | |
| ttx | I should get back to vacationing | 21:23 |
| ttx | mnaser: I'll read your thread or your governance charter change proposal when I get back :) | 21:24 |
| ttx | (I agree something has to evolve, I'm just not sure what yet) | 21:24 |
| mnaser | ttx: get back to vacationing! :P | 21:25 |
| *** e0ne has joined #openstack-tc | 21:29 | |
| *** e0ne has quit IRC | 21:43 | |
| mnaser | tc-members: http://lists.openstack.org/pipermail/openstack-discuss/2020-March/012950.html | 21:48 |
| *** slaweq has quit IRC | 22:09 | |
| *** slaweq has joined #openstack-tc | 22:11 | |
| *** slaweq has quit IRC | 22:16 | |
| *** slaweq has joined #openstack-tc | 22:33 | |
| *** slaweq has quit IRC | 22:39 | |
| *** slaweq has joined #openstack-tc | 22:41 | |
| *** slaweq has quit IRC | 22:46 | |
| *** slaweq has joined #openstack-tc | 23:11 | |
| *** jamesmcarthur has quit IRC | 23:16 | |
| *** slaweq has quit IRC | 23:16 | |
| *** tosky has quit IRC | 23:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
