)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"6f731a341b0771466101f1fc624e51693287e396","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2a5ddc16_6b3d2b88","updated":"2021-12-26 17:58:59.000000000","message":"Looks good. Would not be safer to merge it after 0.12?","commit_id":"d5a0e844349cf533b8745d033e7f94fed9da29a9"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"1f69088fae9f6fc6be178cf9b7ef1dbc1c326369","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"abbba3a5_55036176","updated":"2021-12-26 21:37:38.000000000","message":"Thanks for the review.\nYes, can be merged after v0.12.0, but then it\u0027s better to delay also 6703! This unrequested ACK, together with the delayed connection with keep_alive in 6703, causes lldb to fail the initial handshake with openocd and drops the connection. That\u0027s why I have queued it before 6703.\nThen 6771 fixes a more random error, in around 50% of cases it make the connection to fail.\n","commit_id":"d5a0e844349cf533b8745d033e7f94fed9da29a9"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"227b84a326c39246237389a02ab26d8696ce7106","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2f192f63_0c0a966f","in_reply_to":"abbba3a5_55036176","updated":"2021-12-27 07:15:34.000000000","message":"Ok, as soon as the 6703 is ready we can merge the whole chain.","commit_id":"d5a0e844349cf533b8745d033e7f94fed9da29a9"},{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"52a20fef2674ec2c3cfc38ff58b43dc8d7bc84d8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"17e15ab1_b1f248d6","updated":"2024-02-26 13:32:27.000000000","message":"I can confirm that per our internal testing, this first (unsolicited) ACK character is redundant for LLDB debugger.\n\nWe even encountered a case when this extra ACK was actually dangerous! On a network connection with high latency, this extra ACK could have been mis-interpreted by the client (debugger) as a response to its first message, causing wrong pairing of further requests and responses and a subsequent collapse of the debug session. \n\nI am happy to see it removed. :-)","commit_id":"dfbf2eb60b756f66a665e42d1f796a5006395838"},{"author":{"_account_id":1002161,"name":"Anatoly P","email":"kupokupokupopo@gmail.com","username":"ecco_the_dolphin"},"change_message_id":"6636ab91b127ba240d6ab93edee003ca6f476b70","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"085212ed_0ffd8501","updated":"2024-03-01 05:17:31.000000000","message":"I was always confused by this part.","commit_id":"dfbf2eb60b756f66a665e42d1f796a5006395838"}]}