)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a425551e85dd4d1a283c717f1d15b0178d024d36","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8b96f764_ecd5d330","updated":"2026-06-25 12:23:39.000000000","message":"I\u0027m a bit hesitant to approve this as Sean you wrote the patch and also you +2it.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"736e5ef9e737aa140fc6104ec7dd14d45dc59f42","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"25188ab2_c03f6553","updated":"2026-06-29 17:37:01.000000000","message":"Just want to throw my opinion in here that +2ing your own patch \"because the LLM wrote it\" is not okay with me. IMHO the community guidelines of \"the human is responsible for the submission\" means you lose your +2 abilities by being the responsible one. And please, let\u0027s not even discuss giving agents their own gerrit accounts...","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"87b0b33814045cfa8bac821347107af1be00b312","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1dd37527_e239088d","updated":"2026-06-26 20:25:45.000000000","message":"This looks OK to me and I will approve as the second non-author.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2368fb941e96e98db682646ea5ae28c23e57f979","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8a83e30c_f2147ca6","updated":"2026-06-23 13:34:28.000000000","message":"addressed my own requests for extra testing","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b9025aafd66e239a6f2fed6a5286dd8263802ee0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bcaf2dda_060874ac","in_reply_to":"34ccd84a_9c0ca71e","updated":"2026-06-30 11:57:31.000000000","message":"so i tought we had already dicssed this at the last ptg and agreed to treat test only patch and other povably correct trivial fixes as requiring only one core.\n\nyour right that i confused the matter by +2\u0027ing as i shoudl have just left it such that you could have +2w if you agreed.\n\n\nthat is why i was separating the llm usage form this conversion\nsince that woudl have applied if i had wrote it.\n\nthat is incldued in all the proposal that stephen had made\nhttps://review.opendev.org/q/topic:%22nova-cores-proposal%22\n\n```\nWhat constitutes \"non-trivial\" is of course subjective, but it\nincludes things like obvious typo fixes or small, provably correct bug\nfixes.\n\n```\nwhen we were discussing that it was in the context of small chagne like thi add a test, liniter bumps, typos ectra.\n\nthose would need 1 core in additon to the autor to apporve.\n\nso that why i said the is not related to llm at all and its incorrect to conflate the too.\n\ni obvisly came away form that ptg session with a diffent understanding since i thought we committed to implement one of the 4 options this cycle and that we wanted to treat small test only patch the same as docs only patch or other trivial chagne as not need 2 cores.\n\nnote i very deliberately did not +w this patch and left it for at least 1 other core to review.\n\nthis isnt a ai related topic but if we want to have an ai related discussion as well im fine with that, but indepently of this patch or this topic in general.\n\nnormally i jsut write the regression test \n\nhttps://review.opendev.org/c/openstack/nova/+/989029/1\nand let the patches sit https://review.opendev.org/c/openstack/nova/+/904060/5\nwhich i guess i shoudl have done in this case.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b4a53db5b9c3ec299e555e6684d06645cb2cf5ab","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"90ede718_eb993ffc","in_reply_to":"3f710631_edc97097","updated":"2026-06-27 09:24:04.000000000","message":"so triviality is relative\n\n\nto me this is a trivial patch for a number of reason but that is not the only reaosn i think +2 in this case is valid.\n\nall 3 of use agreed that the relevelnt code is a valid regression test\nmy +2 was based on my review of the code that i generated  entrily without modificaton with a very trivial set of promts\n\nhttps://paste.opendev.org/show/bYrBLyreyi9XLH3RORs3/\n\nthe first 3 prompts wer the inital plan i maed witht he agent at wich point i approved the work\n\n```\nLine 4 — 2026-06-23T11:04:16.894Z\n\n │ this commit fixes an issue with the mtu in our cache for interfacces that are attached to an instance. however it should have had a funcitonal regression test for the bug per my comments\n │ inline can you use the grt comments tool to retrive the review comments then lets plan to create a functional regression test following a green green patther where the regression tests\n │ first assert the currnt bug (mtu is missing when adding an interface form a network not alredy attached to the vm) then the fix commit will update the assert to assert the fixed behvior.\n │ we shoudl provider the expected final assert as a comment in the inital patch per our normal 2 commit process for bugs. https://bugs.launchpad.net/nova/+bug/2080531 is the bug report.\n │\n │ lets plan this toghther then buidl it\n\n Line 74 — 2026-06-23T11:10:26.813Z\n\n │ no we will add the new test in the dedicated regression squite @nova/tests/functional/regressions/\n\n Lines 85-88 — 2026-06-23T11:12:20.466Z\n\n │ i want 2 regression tests 1 for live migration as reported in the bug and addtion just covering the interface attach asserting the db content\n\n │ you can add more if useful\n\n │ the live migration failure is a sideeffect of the initial attach issue\n\n │ so those are the two most important aspects to validate\n```\n\nin the initial review feedback\nhttps://review.opendev.org/c/openstack/nova/+/936093/comments/88581a2a_44fc8ba5\ni gave to the author i actully pointed them at a patch form artom\nhttps://review.opendev.org/c/openstack/nova/+/791235/3/nova/tests/functional/libvirt/test_live_migration.py\nto repoduce this exact issue.\nthat whoever as writtien in nova/tests/functional/libvirt/test_live_migration.py\nand i specificly wanted a freestandign regression test for this bug.\n\nso the llm drew form  https://github.com/openstack/nova/blob/master/nova/tests/functional/compute/test_live_migration.py#L241-L278\nto know how to assert the network info cache contet adn the patterns in teh exsiting regression test areound live migriton testing to conform with https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/README.rst#writing-regression-tests\n\nwhen it had fully implemnteded it and it automaticly tired to test it i saw tox was failing before runign any test becuase the orginal authors patch \nhttps://review.opendev.org/c/openstack/nova/+/936093/2\nwas 18 months old so it was using older tox/requires defion and was breakign due to setuptools changes that happend since it was written.\n\n```\nLine 166 — 2026-06-23T11:21:22.338Z\n\n │ you should not need too work aroudn setuptools issues.\n │\n │ do a git fetch then rebase these changes on top of origin/master\n\n Line 214 — 2026-06-23T11:28:38.957Z\n\n │ please runs uvx --python 3.13 tox -e pep8,py3,functional on both commits then add a release note to the second commit and run the reno build as well\n```\nonce that completed i then did another round of review on both patches and only had 1 nit remaining.\n\n```\n Line 269 — 2026-06-23T11:56:37.423Z\n\n │ so we should not use \"fake-mtu\" as the fake mtu we should use 1450 or anohter valid mtu i.e. an int also for the repoducer isntead of checkign if the mtu is none and raise perhaps we\n │ should check if its note equal to the expected value 1450.\n\n Line 280 — 2026-06-23T11:56:54.478Z\n\n │ we can do a targeted validation of those refinement instead of a full test run\n```\n\nat which point i submited them for review.\n\nthat is why it felt approate to +2 this because i weth ther the exact same workflow i woudl have done if anyoen else had written this and asked me to review.\ni do this with all of my patch and basiclly alwasy have.\n\nin this case if we go back to tiviality\n\nits a test only patch, which means it has no runtime impact on enduers or operators and in most case is nto even present on a production system as test are typically packaged separately. as such the risk fo this patch impacting anyoen other then a contibutor or packagere is zero.\n\n\nfor us the risk is also low but non zero as this could impact ci stablity\n\nthis type of test only change that proves the exisitng of a bug i think is a canonical example of a trivia change along side type, docs only change, ci only change or other chagne that are trival to prove correct with minimal risk to others.\n\nwhile i acknoldage the concern rasied i think we realy should normalise this as the norm when a core feels they have done tehre due dilagenace.\n\nthe alreadyitnve are i -1 fix patch to make it clear that this is waiting fro the autor add the request testing and continout to wait for them to adress that, or write this patch plascing it ahead of the fix to follow or normal regression process knwoitn that that now blocks the fix from progressing.\n\ni only created this patch because gibi express interest in progressing the fix. if i a core cant count towrard the 2 cores in this case we are efectivly sayign when ever an operator or someone who is unresponce fixes a bug that impacts them but cant add the tests or doc to properly supprot the fix we now need 3 cores or we merge a lower quality fix and then adress teh techinal debt create by that in a follow up that will be even less compeling to review and backprot and still efectivly increae the core requiremnt form 2 to 3\n\n\neven without the use of ai i think this is very much in the sprit fo our core reviewer policy but im happy to have that conversation more widely if needed.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"87b0b33814045cfa8bac821347107af1be00b312","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3f710631_edc97097","in_reply_to":"8b96f764_ecd5d330","updated":"2026-06-26 20:25:45.000000000","message":"Agree this seems a bit much to be +2ing one\u0027s own patch -- I get that this is to support another contributor who wasn\u0027t able to write the func test we need but it is still 136 LOC and not trivial.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5733c966c5440ae9fe42c9e26087e48d97aa6f01","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d4f8e098_ebadd5ea","in_reply_to":"90ede718_eb993ffc","updated":"2026-06-29 18:15:23.000000000","message":"\u003e i only created this patch because gibi express interest in progressing the fix. if i a core cant count towrard the 2 cores in this case we are efectivly sayign when ever an operator or someone who is unresponce fixes a bug that impacts them but cant add the tests or doc to properly supprot the fix we now need 3 cores or we merge a lower quality fix and then adress teh techinal debt create by that in a follow up that will be even less compeling to review and backprot and still efectivly increae the core requiremnt form 2 to 3\n \nI completely understand why you did this and I have a lot of personal experience -1\u0027ing someone\u0027s patch for lack of test coverage, providing the test coverage patch for them myself because I did not want to block the fix due to missing test coverage, and the drawback for me was that I could not +2 the test that I wrote for them. So it\u0027s possible I understand the reasoning here more than most.\n\nAnd I get that using an LLM seems like a way around this because then I would not have written the code myself ... I think it\u0027s a grey area, at best. Currently the community guidelines treat LLM generated code as the author\u0027s own. And I think it\u0027s pretty difficult to consider doing anything else at the moment. Maybe things will evolve but for now, that is the situation I think.\n \n\u003e even without the use of ai i think this is very much in the sprit fo our core reviewer policy but im happy to have that conversation more widely if needed.\n\nYeah I mean, if you are going to do these then I think we need to have a wider discussion in the Nova team and get on the same page before this gets out of hand. And since it also seems in \"AI guidelines\" territory, the discussion might need to be even broader at the OpenStack level.\n\nAt a minimum, I think the Nova team needs to get on the same page about this sort of patch voting, otherwise it creates a lot of stress.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cef5c389f38bede022653c1e26871ea45b619218","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b481c477_3680bbdf","in_reply_to":"a6f6e6d4_f1a75278","updated":"2026-06-29 20:12:29.000000000","message":"\u003e actually the llm usage is not really the reason or it but ok i will prefer to -1 and not create the test coverage unless the change is one im personally invested in finding other cores to review the test coverage patch.\n\u003e \n\u003e \n\u003e in this case gibi highlight that the issue still existed and wanted to know how  to move forward.  i did comment on the patch that form my perceptive the reason this had not moved forward was because the author had not added the missing test coverage.\n\nOK, perhaps this is the main point of the issue. I think finding other cores \"should\" not require much investment. We should be helping each other ... and that is why I found this patch. I want to help people land bug fixes, whether they involve me previously or not.\n\n\u003e and yes this create a lot of stress for everyoen inclduing me. that why i was thinking about this and relying at the weekend.\n\n++ To be clear, for me stress is removed when there is a clear team understanding on a thing and I don\u0027t have to analyze it every time I come across it. That\u0027s why I mentioned about team discussion. I don\u0027t want to be close-minded about things, I just want to be clear if most of the team would like to adopt a norm or pattern, that I know about it and so it will be easy for me to operate with it.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"4c1a44eeb1e8e487541e339f78b252ef64a99bb2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"34ccd84a_9c0ca71e","in_reply_to":"b481c477_3680bbdf","updated":"2026-06-30 08:33:47.000000000","message":"From Sean:\n\u003e that is why it felt approate to +2 this because i weth ther the exact same workflow i woudl have done if anyoen else had written this and asked me to review.\n\nFrom Mel:\n\u003e Yeah I mean, if you are going to do these then I think we need to have a wider discussion in the Nova team and get on the same page before this gets out of hand. And since it also seems in \"AI guidelines\" territory, the discussion might need to be even broader at the OpenStack level.\n\nI agree with Mel here. This might be OK on personal level, but it was pretty much not discussed with the core team if we are OK with it or not on organizational/process level. \n\nAnd as much as we would like to separate this form LLMs we cannot. If a human writes this patch then that human can propose it and take some level of responsibility for such proposal. Then you can review it and discuss nits and fixes with the author in the review, the author would respin and then you eventually +2 it. In the other hand when a LLM writes it these steps are missing / not visible. Your review and co-working with the LLM is not visible in this current review for others. Only a blank self +2 is visible.\n\nAnd I know it is a hard discussion to take but I guess now it is even harder to discuss as we added some extra tension to it. :/ But we need to talk about it as a team.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"86b695e93d7fba2d63989b65eadf4bc47c27fdad","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"09e67f6a_c9dcd889","in_reply_to":"bcaf2dda_060874ac","updated":"2026-06-30 15:23:42.000000000","message":"I feel that by not able to get to a compromise with the 4 proposals that the whole core team can agree to is actually an independent, and serious problem. \n\nI still stand by that in this case it would have been better to ask the team and confirm before the self +2 or even just to add some explanation that you are self +2 because of a certain proposal / agreement from the PTG as this is something new or unusual.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"09e5959b2dabd6ba5d8d63d248287c4f0de44c9a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a6f6e6d4_f1a75278","in_reply_to":"d4f8e098_ebadd5ea","updated":"2026-06-29 19:25:18.000000000","message":"actually the llm usage is not really the reason or it but ok i will prefer to -1 and not create the test coverage unless the change is one im personally invested in finding other cores to review the test coverage patch.\n\n\nin this case gibi highlight that the issue still existed and wanted to know how  to move forward.  i did comment on the patch that form my perceptive the reason this had not moved forward was because the author had not added the missing test coverage.\n\nand yes this create a lot of stress for everyoen inclduing me. that why i was thinking about this and relying at the weekend.","commit_id":"fe468526ec4257d439e60f377f05ad83b9882f79"}]}