Wednesday, 2025-05-07

opendevreviewMerged openstack/openstack-manuals master: Glossary - remove VirtualBox  https://review.opendev.org/c/openstack/openstack-manuals/+/94865000:19
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896100:22
opendevreviewDmitriy Chubinidze proposed openstack/openstack-manuals master: Update "availability zone" term in Glossary  https://review.opendev.org/c/openstack/openstack-manuals/+/94861807:25
opendevreviewMerged openstack/openstack-manuals master: Add Rocky Linux to Glossary  https://review.opendev.org/c/openstack/openstack-manuals/+/94873112:15
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896112:25
opendevreviewDmitriy Chubinidze proposed openstack/openstack-manuals master: WIP: Add AlmaLinux  https://review.opendev.org/c/openstack/openstack-manuals/+/94903413:45
opendevreviewDmitriy Chubinidze proposed openstack/openstack-manuals master: Add AlmaLinux to Glossary  https://review.opendev.org/c/openstack/openstack-manuals/+/94903413:55
mnaseri'm finding it harder and harder to land code in openstack projects lately15:07
mnaser(and if I'm struggling, i can't imagine new contributors having a good time)15:07
mnaserfor example, i have a trivial backport that's open for 22 days.. but other changes are being merged15:08
mnaseri feel like we need to have some sort of project-wide way of pinging cores for reviews and tracking it15:12
*** ralonsoh is now known as ralonsoh_out15:15
frickleras core for a lot of projects, my impression is that I get rather pinged too much, so I'm not sure I'd advocate for even more pinging. otoh I acknowledge that important reviews do still get missed16:08
fricklerwhat does help in my experience is getting to know the project better, which helps with knowing whom to ping who would actually be interested in doing a review and have time for it, but again I agree that this isn't an option for everyone16:10
fricklergetting better at removing inactive cores might also be an option, but then, only doing a single review per cycle might still be valuable, so that's often a tough decision, too16:11
mnasiadkaI think it's rather something we should analyse project-by-project instead of just assuming it's that bad everywhere16:12
fricklerwell I'm not aware of any project that isn't struggling with review backlog, but yes, different shades of red are definitively at play there16:14
gouthamrpeople are busy and code-reviews and maintenance is a side job for most.. i've found that having some scheduled activity works: review jams every week? personal review block? review assignments from PTLs16:14
mnasiadkaWell, there's a lot of people that just want to land a feature, and there's only a handful of reviewers that are rather focused for the project sustainability in terms of maintenance and stability16:18
gouthamryes16:18
mnasiadkaIn Kolla I think it did help a bit that we allowed the community to deliver a list of patches that they would like reviews on - in ideal world that wouldn't be needed because all patches would be reviewed on time - but we're past the initial hype where a patch had more than 2 reviewers :)16:19
gouthamrwe should keep advocating for "earning trust" ... drive by contributors are welcome, but, reviewers are definitely going to pay more attention when you show up and help review other changes, or address tech debt/help with project maintenance in addition to chasing feature changes16:20
gouthamrits human nature16:20
mnasiadkayes, it's a lot better if somebody shows up on the weekly meeting or just does some interaction on the IRC channel regarding his contribution16:21
mnasiadkaAnd we have a lot of contributions where people do not update the patch ever beyond PS116:21
mnasiadkaAnd that's how we end up in a place that we usually review patches by known contributors or other core reviewers, because we know they are going to persist on adapting the patch as per reviews - compared to spending at least 15 minutes on a patch that will never get updated.16:22
opendevreviewDmitriy Chubinidze proposed openstack/openstack-manuals master: Add AlmaLinux to Glossary  https://review.opendev.org/c/openstack/openstack-manuals/+/94903416:48
gouthamrhave we ever considered using the reviewers plugin on review.opendev.org?16:48
gouthamrit _may_ help16:48
gouthamrreviewers ofcourse could totally ignore changes even with review prompts16:49
mnasermaybe that might be more helpful, it just feels like it's a big issue that needs to be figured out for sustainability17:18
JayFfrickler: I *hope* Ironic doesn't have a severe problem with review backlog. I personally really, really try to ensure things don't get lost even if I'm not always successful17:20
gmaanwhile fixing multiple things in many projects for example, rbac, CI, tempest plugins, I have observed that many project lack in review frequency and many time it is once or twice in a week (soimetime month). 17:24
gmaanthat is very common for core who are part time doing the upstream activity17:24
gmaanI feel asking projects to implement the 'Review Priority' label and at least monitor those priority review weekly meeting/office hour/or-sometime-in-week can solve such situation17:26
gouthamrmeh 17:27
gouthamrthe RP hasn't really helped :( 17:27
gouthamrpersonal opinion perhaps17:27
gouthamrbut, its a binary flag, and you could have too many things prioritized, and hence ignored17:28
gmaanfrickler: on core cleanup list, I think it create more confusion to have list out of dated than having review help sometime. But at least we can cleanup who are clearly not active at all.17:28
gmaanRp can only be helpful when team monitor those weekly basis17:28
gmaanif they do not then yes it does not make sense either you tag them as priority or raise multiple places17:29
gmaanat least it is working fine in QA 17:30
JayFI think the path Ironic took of separating approvers/reviewers so we could be more generous with giving newer contributoes a +2 is an option too17:30
JayFespecially if we can garner enough trust between projects to make it easier for a primarily project X developer to have some review rights on project Y17:30
mnaseris this akin to the approvers/reviewers that k8s runs?17:30
mnaserlgtm/approve?17:30
JayFI do not know how k8s does anything :) 17:31
JayFbut in gerrit terms, cid and cardoe have +2 code review votes but not a +1 workflow17:31
mnaserhttps://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process17:31
gmaanalmost yes, they have same, reviewers can lgtm but not merge. and only few other can approve the things17:31
gmaaneven 'member' and 'reviewer' both can lgtm but lgtm from 'reviewer' is helpful for approver 17:32
JayFso people in that group are able to contribute reviews, but we ensure that at least one more senior team member has to review something to land17:32
mnaserand that group is very vast, because its anyone part of the k8s (or specific github org)17:32
mnaseraka anyone in kubernete-sigs can lgtm17:32
mnaserand barrier for org joining is low, just need to get sponsored and show impact in the project17:33
JayFit's certainly not that vast for Ironic; but I do think being more open is a part of the path17:33
gmaanyeah but I have seen approver check 'Reviewer' lgtm as key input17:33
mnasermaybe we need to auto close things after 90 days to avoid noise17:34
gmaanso there is distinguish list of 'Reviewer' maintained per repo in k8s which is where it is more helpful 17:34
gmaanI am 100% sure auto close thing will not work because core member can have a simple gerrit query to list reviews with zuul+1, no -1, open changes 17:36
gmaanit is about many projects does not even check open reviews/state of project for weeks, many might be showing up during release time only17:36
JayFyes17:37
gmaanif core check open reviews weekly basis, it makes situation better17:37
JayFwe shouldn't pretend this is about visibility of reviews17:37
JayFit's about people not checking or purposefully prioritizing reviews from people/features they are more engaged with17:37
gmaanyeah17:37
JayF"Wow this project moves slow, but that makes sense it's feature complete" is a different experience than "Why have ten other patches gotten reviewed and landed and I don't even have a comment?"17:38
JayFeven /if/ there's a reason for the prioritization, it's a bad experience and not communicated in any visible way in gerrit17:38
gmaanmnaser: if you do not mind pointing those project it will be helpful for TC to keep eyes on that. As you know, we do keep eyes on gate tests/release etc but input about reviews/not merging things can be helpful 17:40
gmaanat lest we could bring it during election to PTL candidates/DPL liaisons that this is problem this project facing and what their plan to solve it17:41
mnasergmaan: for example, https://review.opendev.org/c/openstack/cinder/+/910700 is almsot a year open, and we've been running it locally in atmosphere because we can't wait that long for things to land17:42
mnaserhttps://review.opendev.org/c/openstack/ovn-octavia-provider/+/945798 minor bug fixes open for a month17:43
mnaserhttps://review.opendev.org/c/openstack/ovn-bgp-agent/+/947151 backports nearing a month of what should be relatively straightforward..17:44
mnaserhttps://review.opendev.org/c/openstack/ovn-octavia-provider/+/942940 sometimes even such trivial stuff makes me wonder if they're even being actively checked17:44
mnasersometimes we'll push up stuff, get a lot of back and forth - https://review.opendev.org/c/openstack/horizon/+/924729 -- we get distracted with other stuff, only for it to land later with almost the same fix -- https://review.opendev.org/c/openstack/horizon/+/935854 -- but ours was "we need a unit test" and this one shipped right through17:46
gmaanric replied on cinder one, it seems waiting for one review comment. slaweq ^^ can help to land neutron ones. 17:47
mnaserright, rico had to ping a month ago after it sat idle for many months .. and i totally get it, we can find ways to help land them, but i'm trying to dig a bit at the root cause rather than just .. ok for this we can do that17:47
gmaanhorizon one is surprise, not sure why one need unit test and other do not :)17:48
gmaanI feel that is where Review Priority worked well in QA but those needs to be open for non-core also. if we see RP label +1 by author we do check and add core RP label also it helps to keep unnecessary/large list of RP to reviews.17:50
gmaanbut again project needs to monitor those Rp changes weekly basis17:50
gmaanits a simple way to filter key reviews to look if they missed those due to other work or so17:51
gmaanbasically way for author to express how important that change is17:51
JayFBut like, even a less important bugfix shouldn't be allowed to sit indefinately17:53
JayFit's not a situation where sometime, 6 months later when someone has time they'll review it17:53
JayFI've never had a review that sat for longer than 2 weeks without a review *get* another review until I pinged someone; maybe holidays excepted17:53
gmaansure, but without some filter, project things everything goes in least priority list. having priority list does not stop them to review all which they should anyways17:55
gouthamr+1 review priority coordinated through gerrit, or review focus through review-jams or etherpads with weekly check-ins will help sort out what the team can deem "important".. but we wouldn't solve the problem of stagnating patches.. 17:57
gouthamrat the PTG, i briefly highlighted the review dashboard from bitergia that PTLs/core reviewers could use.. carloss found this information useful to shepherd languishing changes, and motivate cores17:57
gouthamrfor the lack of a legit url shortener: 17:57
gouthamrhere's a view of how cinder did from Sep 2024:17:57
gouthamrhttps://openstack.biterg.io/app/dashboards#/view/8c515590-e1de-11e8-8aac-ef7fd4d8cbad?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:'2024-09-16T21:17:53.449Z',to:'2025-04-01T21:18:03.038Z'))&_a=(description:'Efficiency%20panel%20for%20Gerrit%20by%20Bitergia',filters:!(('$state':(store:appState),meta:(alias:'Changesets%20Only',disabled:!f,index:gerrit,key:type,negate:!f,params:(query:changeset),type:phrase),query:(matc17:57
gouthamrh:(type:(query:changeset,type:phrase)))),('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,controlledBy:'1541521075121',disabled:!f,index:gerrit,key:repository,negate:!f,params:(query:openstack%2Fcinder),type:phrase),query:(match_phrase:(repository:openstack%2Fcinder))17:57
gouthamr)),fullScreenMode:!f,options:(darkTheme:!f,hidePanelTitles:!f,useMargins:!t),query:(language:lucene,query:''),timeRestore:!f,title:'Gerrit%20Efficiency',viewMode:view)17:57
gouthamrmedian open time for a patch: 57.028 days17:58
mnaserwell we're gonna need a bit.ly or something for that17:59
mnaser:P17:59
gouthamrlots of other ready dashboards to mine information from there, so i'll not spam you with links18:00
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Glossary - remove Linux Bridge  https://review.opendev.org/c/openstack/openstack-manuals/+/94865318:06
fricklerJayF: oh, I didn't think of ironic, that might indeed be doing quite good18:59
JayFfrickler: I honestly try really hard, it's basically my #1 upstream priority to make sure every change I'm qualified to review (and am core on) gets a review19:15
fungigouthamr: i've not fully caught up on the discussion, but i do still have https://review.opendev.org/724914 proposed to add the reviewers plugin based on a request from starlingx maintainers 5 years ago19:27
fungiit'll almost certainly need a rebase or rework now, if anyone wants to take it over19:28
gouthamrah nice 19:29
fungimaybe also an example of the problem you're discussing ;)19:36
gouthamr"ironic" 19:40
gouthamri rebased the change :D i can volunteer some repos as guinea-pigs 19:41
opendevreviewMerged openstack/openstack-manuals master: Add AlmaLinux to Glossary  https://review.opendev.org/c/openstack/openstack-manuals/+/94903420:19
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Linux Bridge  https://review.opendev.org/c/openstack/openstack-manuals/+/94865320:20
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896120:24
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896120:31
fungigouthamr: as noted in my earlier comments, we'll also need a mechanism (in opendev/jeepyb manage-projects would be the most appropriate) to push the reviewers files into gerrit for it too21:07
* gouthamr will look21:07
fungiand anyway, i won't be able to review until next week at the earliest21:07
gouthamrunrelated: i forgot that the proposal bot patches keep getting respun if we let them sit for a while.. these glossary updates are now broken down like we want, except they also spawn a bunch of bot changes 21:08
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Cloudpipe  https://review.opendev.org/c/openstack/openstack-manuals/+/94863721:08
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Glossary - update for term Scoped Token  https://review.opendev.org/c/openstack/openstack-manuals/+/94864621:09
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896121:12
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Xen  https://review.opendev.org/c/openstack/openstack-manuals/+/94865121:15
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Sahara  https://review.opendev.org/c/openstack/openstack-manuals/+/94864521:15
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Panko  https://review.opendev.org/c/openstack/openstack-manuals/+/94864421:15
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove nova-network  https://review.opendev.org/c/openstack/openstack-manuals/+/94865521:16
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Murano  https://review.opendev.org/c/openstack/openstack-manuals/+/94864221:16
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove TripleO  https://review.opendev.org/c/openstack/openstack-manuals/+/94864821:16
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Glossary - remove Senlin  https://review.opendev.org/c/openstack/openstack-manuals/+/94863821:17
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Glossary - remove Senlin  https://review.opendev.org/c/openstack/openstack-manuals/+/94863821:17
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Glossary - remove Senlin  https://review.opendev.org/c/openstack/openstack-manuals/+/94863821:19
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896121:22
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896121:41
opendevreviewMerged openstack/openstack-manuals master: Glossary - remove Senlin  https://review.opendev.org/c/openstack/openstack-manuals/+/94863821:45
opendevreviewOpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals  https://review.opendev.org/c/openstack/security-doc/+/94896121:54

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!