)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"a4b8c625fb123e221f40f51650c186f2a84a5b08","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0fa269df_153d7af2","updated":"2026-07-24 18:43:53.000000000","message":"\u003e Thank you @fungi. Abandoning since there\u0027s consensus to preserve the DPL model. Thank you all for all the attention that you give to the Release Management team!\n\nprior to abandoning this change, I didn\u0027t realize that ttx would remain on the release liaisons for now, even if he was replaced as a security liaison. \n\nThe release management team discussed this [1], and I agree that this liaison role is well staffed, and, may not be as useful to the release management team as it would be on a service project team - everyone on the release management team can be considered \"release liaisons\" for the community\u0027s perception and the tooling doesn\u0027t break because of this.\n\nthat said, whether ttx chooses to remain a liaison or not for governance purposes, we know he\u0027s plugged in, aware, and both him and the team satisfies the TC\u0027s \"healthcheck\" requirement that drove \"DPL resets\" between cycles. \n\nI\u0027ll mention this at the TC\u0027s meeting as well and we can formally note any issues with my understanding here\n\n[1] https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-07-24-14.00.log.html#l-114","commit_id":"9fe6724d0d3bb4cd5eddeedd38b6285d8636c9c2"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"4e55544a92da284e54e50491a1380631ff76f796","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"27b7bdb7_71aa9423","updated":"2026-07-15 08:10:55.000000000","message":"i guess we all want to stick to distributed leadership type","commit_id":"9fe6724d0d3bb4cd5eddeedd38b6285d8636c9c2"}]}