Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-06-17
16:24:44 Uggla gibi do you want to share something ?
16:27:29 bauzas I guess he provided a revision so the next need will be to review it
16:27:43 bauzas (which is something I'll do)
16:28:21 Uggla I know he added some stuff on top of the serie to improve logging.
16:28:31 gibi sorry
16:28:38 gibi to many discussins in parallel
16:28:44 gibi so
16:29:02 gibi thanks for the review I fixed most of the comments we gathered on the last weeks sycn
16:29:37 gibi there is one comment form sean-k-mooney about the spanwissynchronous fixture I have to work on
16:29:37 opendevreview Abhishek Kekane proposed openstack/nova master: Revert^2 "Support glance's new location API" https://review.opendev.org/c/openstack/nova/+/950623
16:29:46 gibi it actually pointed to an independent nova bug
16:29:53 gibi I linked to the channel last evening
16:30:06 gibi other than that the series is reviewable
16:30:25 gibi and yes there are some logging improvement on top of the series based on the last week's sync
16:30:48 gibi and at some point I will add one proposal to the futurist lib as well for executor utilization
16:31:08 gibi other than this I dropped a "bomb" on the mailing list
16:31:17 gibi about the eventlet removal timelien
16:31:26 Uggla using spawn instead of fork ?
16:31:28 gibi as 2026.2 is pretty streched for us based on our progress
16:31:46 gibi Uggla: nope just utilization logging
16:32:02 Uggla ok
16:32:05 gibi I have to go back to that ML thread as there are replys
16:32:50 gibi I expect TC will be involved
16:32:53 gibi that is all
16:33:13 bauzas We'll discuss it today at the TC meeting
16:33:14 Uggla maybe we could discuss news about that in the weekly meeting about eventlet.
16:33:15 gmaan I think we will be discussing it in today meeting
16:33:22 gmaan yeah
16:33:27 sean-k-mooney gibi: are you refering to the spawn_on interaction or a diffent nova issue
16:33:30 bauzas In the open discussion
16:33:49 bauzas (I added the topic?
16:33:54 bauzas )
16:33:56 sean-k-mooney gibi: we dont need to go into detail just wondering if it was somethign else
16:34:07 gibi sean-k-mooney: yepp the spawn_on pointed to the bug I linked yesterady about the decorator on the build_and_run_instance
16:34:17 sean-k-mooney oh that
16:34:24 sean-k-mooney ok thanks for the context
16:34:27 gibi nhp
16:34:29 gibi np
16:34:44 gibi btw this is the eventlet removal ML thread https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/BIC7BTAN72X6AA4BE6VVNSP7FYFOC362/
16:34:48 gibi just for the record
16:34:58 Uggla +1
16:35:31 gibi that is all from me
16:35:42 Uggla thx gibi, moving on.
16:35:46 Uggla #topic Bridging the Gap: metrics and survey analyses
16:35:48 fungi i'll try to be quick, but there's a lot we dug into... for some background on openstack-wide metrics analysis see ildikov's most recent ml post yesterday:
16:35:52 fungi #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/NTBNI7YIDCWBR6BTPEKVZIODWTVUIOXO/ BtG metrics analysis
16:35:59 fungi also could be worthwhile to revisit her previous post in that thread going over the contributor and survey results (and anyone who hasn't filled those out for epoxy, please see if you can find a few minutes to do that!)
16:36:09 fungi as a follow-up activity, we've started doing some team-specific analyses, focusing on teams that had multiple contributor and maintainer survey responses
16:36:19 fungi the contributor survey had 2 responses for nova and both respondents had contributed for at least 2 years and were contributors to at least two other open source projects
16:36:29 fungi most feedback was relatively neutral (averaging 3-3.5 out of 5) with the lowest score being a 2 on "Changes you propose are reviewed in a timely manner"
16:36:43 fungi "You receive actionable feedback from other reviewers" had the widest skew, with a 2 and a 5 from the respondents
16:36:56 fungi top challenges reported were trouble with review attention, unhelpful comments and reviewers asking to expand the scope of the change
16:37:04 fungi additional feedback noted that the team seemed to have more work backlog than people available to manage it, and that change prioritization seemed to be a struggle
16:37:13 fungi the maintainer survey also had 2 responses with overall higher scores than the cntributor survey (averaging 3-4.5)
16:37:22 fungi contributing challenges reported were similar to those from the other survey, but specifically called out slow review times leading to changes with one +2 falling into merge conflict and repeatedly having to be rebased and re-reviewed, eating up more maintainer resources
16:37:31 fungi the top challenges with reviewing were changes without a spec/blueprint, low-priority changes, and contributors failing to address review comments or ci failures
16:37:46 fungi other comments included struggles in agreeing on automated tooling, and inconsistency of style/lint choices between different openstack teams
16:37:54 fungi looking at metrics we gathered from gerrit for the past 5 development cycles, we saw caracal was particularly slow for reviews (also observed for cinder), not sure what the cause was but then things got somewhat better again in the past year
16:38:08 fungi number of changes that don't get merged within a cycle were fairly steady over time except for epoxy where it spiked, and review times seemed consistent with contributor survey observations
16:38:23 fungi finding some way to improve the time to first review might help keep contributors, new and established, involved and engaged
16:38:33 fungi trying to balance out first review time between new/casual contributors and established team members/maintainers could also help
16:38:42 fungi probably the biggest and most actionable suggestion to is better/clearer communication in reviews that are done, particularly increasing transparency with regard to change and spec prioritization
16:38:49 fungi sorry, i know that's a pretty big info dump (i tried to pare it down as much as possible
16:38:58 fungi if ildikov's around she might also have additional comments
16:39:42 fungi also if anyone has questions, i'm happy to try and answer them either here in the meeting or in irc after
16:40:19 gibi what my pretty tired mind got this from is: so basically we should say no to new specs early instead of approving them and then not reviewing the implementation in time
16:40:20 fungi this is still just the beginning, we'll be continuing to run the surveys and refine some of the gerrit metrics we've been looking at
16:41:07 fungi gibi: yes, that's a great insight. having some feel for what your future review bandwidth might be and keeping conservative about over-committing to feature work especially
16:41:22 gibi then we will get the feedback that we are hostile for proposals
16:41:34 gmaan I am sure the feedback for this will be 'nova stopped accepting new request/features'
16:41:38 gmaan gibi: ++
16:41:48 gibi this is a very hard thing to balance
16:41:53 sean-k-mooney im not sure if SLUPR effect impacted caracal. nova POCed the slurp process for yoga to antelope
16:41:59 sean-k-mooney but caracal was the first offical one
16:42:32 fungi i don't think it's out of line to say that the team has limited review bandwidth and is prioritizing fixing bugs over adding features
16:42:37 sean-k-mooney nothing else specifcally jumpst out at me in that timeframe that made it special
16:42:56 fungi slurp is a great guess there, i agree
16:43:47 ildikov Apologies, I’m in transit, but trying to follow along and add comments if helpful
16:43:49 gmaan I think one question should be included in survey that people who are not getting enough reviews do contribute in community/nova also ? if no then can they and improve the situation?
16:44:34 fungi but on the spec prioritization subtopic, it still seems like being conservative about approving new specs and telling people there won't be time to review the changes for them (and ask for help fixing bugs and working toward becoing new maintainers) is still going to be a better experience for them than having their specs approved and then not being able to find anyone to
16:44:36 fungi review the resulting changes
16:45:24 gmaan it is always two way things and sometime I feel that collecting/providing one way feedback is not much helpful. We have been receiving this feedback since many years and I at least did not see any improvement due to that.
16:45:36 fungi writing a spec and having it postponed or rejected is some wasted work, but writing the entire implentation and having it get ignored will leave an even worse taste in their mouths
16:45:37 gmaan but maybe that is just me
16:46:23 gibi I can limit my spec +2 on things where I commit to review the impl and only use my +1 on the rest of the specs
16:46:43 fungi well, i see it as indicating where the project could use the most additional help, and also something maintainers can point to in order to explain why things people want aren't getting done
16:46:45 ildikov I think transparent communication is key, as y’all are saying. I also think gmaan is touching on an important point regarding capturing more contributors to do reviews.
16:46:49 sean-k-mooney we could try that but im not sure how much that will help
16:46:55 gibi but it won't create satisfaction from the contributors as they feature will not land this way either
16:47:00 sean-k-mooney that partly pickign yoru favorit rather then which isready
16:48:04 fungi i also think satisfying ungrateful or entitled contributors isn't a goal, they're generally going to become a time sink, what would help is figuring out how to improve the experience for people who are likely to stick around and help
16:48:31 gibi how do I foresee who will stick around and help?
16:48:36 fungi and yeah, being able to tell the two apart isn't easy
16:48:40 gibi yeah
16:48:53 gmaan IMO, merging the spec is 'we welcome the ideas/feature requests' and if slow/no review in code then yes we face challenge in review bandwidth so help here
16:49:10 gibi should we require one cycle of active bugfixing from someone before we review their spec?
16:49:13 sean-k-mooney i guess folks that engagen in the review positivly and relfect on feedback
16:49:23 fungi but, for example, people who pester me for reviews on things that have only been open a day or two? i tend to ignore them and their changes, or at most explain to them that their expectations are unrealistic
16:49:24 sean-k-mooney is a good indication to some degree
16:49:59 fungi (unless it's clear that the change is urgent for the project and not just for the person proposing it)

Earlier   Later