)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"3e5cdfe694b589e3d0b2d1176f53f3b6678c109d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7481805c_99479f07","updated":"2022-10-19 16:20:05.000000000","message":"Also we should also notice that usually oslo is frozen before the official date for non client libs.\nThe date for oslo is not yet set for Antelope, but we could find a compromize by freezing one or two weeks before the usual date, to avoid loosing one month.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"af7f7cbd979e4cd0a9722dcce7c004f1f0ace58b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"fc49abe5_5bff750f","updated":"2022-10-19 16:30:34.000000000","message":"Also, kudos for not pointing fingers but this was obviously the oslo.db change 😅 It would be nice to have a postmortem on that. Should we have released that change sooner? Absolutely. However, it had to happen at some point. SQLAlchemy 2.0 is a thing and I was shouting about it for over a year with no one listening [1]. There may have been pain here but the pain would have been worse if we were starting from scratch.\n\n[1] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"43e8111ace361e14b3dd1da2a73064a9e82405bd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"dc4da3ee_99190b66","updated":"2022-10-19 16:06:55.000000000","message":"Libraries will lose 1 month... on the other side libraries are stable enough to not require to many new features during each series.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"4a16bc623d14c06006c9b8b0228738733eea88d5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"21161a20_3a3775a8","updated":"2022-10-19 16:15:31.000000000","message":"My main concern is that libraries will lose one month of development period, that let us a window of 3 months of active development.\nClearly from relmgmt viewpoint it\u0027s not a problem, but from a library maintainer point of view this is loosing a good amount of development weeks (speaking from my oslo role).","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"01d1079c77a53d122eea765028c5c955893599f8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"04249fc0_7e7d5fd9","updated":"2022-10-21 11:02:17.000000000","message":"Not convinced. If that ensured that we\u0027d always avoid last-minute release issues, I would support it. But reality is, this covers just a part of our blind spot. There are a lot of reasons why CI for a particular project ends up no longer working, our own library breaking changes is just one of them.\n\nI think the current freezes are enough to cover the risk. Running periodic tests to detect issues earlier would also be great (and cover much more than just library breaking changes)","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"64d5f41b964f78116ee94ca75c2cd6ade2a1ec7e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"85a1355b_8f4078c2","updated":"2022-10-19 16:24:55.000000000","message":"Please don\u0027t do this to oslo. 1 month is far too long not to be able to merge anything. If we want to have a stable $thing this long before the release then that stabilization should happen on a branch other than master.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"2a03926588ffe0600dc39b1fcd81fdb071fea0ad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c75b922b_b8a11162","updated":"2022-10-20 12:44:43.000000000","message":"Stephen makes a really good point that we should have a postmortem about the oslo.db problem.  I think we should do that first before making a larger policy decision.\n\nMy takeaway from the TC discussion was that oslo-consuming projects would like a warning that something big is coming.  But as Stephen pointed out, there have been announcements about SQLAlchemy 2.0 for a long time, so no one should have been surprised that something could break wiht the oslo.db release.  The idea of the library feature freeze is that possibly breaking stuff that\u0027s under development would be announced on the ML to get a FFE, and that would alert all oslo-consuming projects.  On the other hand, it could just be yet another email that no one pays attention to, and extra overhead for an already strapped oslo team.  So before setting this early feature freeze, I think we should look more carefully into what exactly happened and see whether this proposal would have prevented the unpleasantness last cycle.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"64d5f41b964f78116ee94ca75c2cd6ade2a1ec7e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4fe32542_cfcf1b0d","in_reply_to":"21161a20_3a3775a8","updated":"2022-10-19 16:24:55.000000000","message":"Yeah, this ^. This is a long time to be spinning our wheels. We already have a hard time getting reviewer attention and getting stuff merged. IMO for this to happen, the \"freeze\" has to become a \"fork\". In summary, at M2 we will create the new stable branches for the non-client libs which will form the basis of the new release.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"680c392498e8ff41d05f7ef782fdbdbd936495fe","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"938f1c91_bd1cf53c","in_reply_to":"63ce8838_558dc624","updated":"2022-10-19 23:13:11.000000000","message":"Thanks, Stephen and Harve for the feedback which is what we were missing in the PTG discussion and wanted to get in Gerrit.\n\nI agree with both of you and the intention is not to reduce the development cycle for oslo/lib instead we want to avoid any breaking changes happening at the end of the cycle and the project getting broken.\n\nThe idea here is (what Elod mentioned) to provide a soft freeze date (not final) so that anyone pushing oslo changes after that deadline can be more careful about any breaking change. And getting FFE for any big change (oslo team can decide that this might be an incompatible change so let\u0027s go for FFE) so that we at a broader level know that this change is coming. Also, another benefit will be early releases of oslo/lib ( at the soft freeze, FFE) so that the new release version is used as constraints in gate and the project will get to know the breaking change early.\n\nIf you think *feature freeze* naming is a little strong statement here then we can use some other wording something like \u0027backward incompatible change freeze\u0027 or any better word. idea is to notice/carefully test the incompatible changes coming/releasing after this deadline.\n\nPlease let us know if that works for you. or feel free to propose any other idea to avoid having incomaptible changes released at the close of final release.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"d7797c80c091980005a1e660f85e59a53cf9ff4d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"89f676da_cb3190d3","in_reply_to":"85a1355b_8f4078c2","updated":"2022-10-20 06:52:12.000000000","message":"I agree with that.","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"d8be158d8f9f6f3a24fd1bb78638340dc6944689","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"63ce8838_558dc624","in_reply_to":"fc49abe5_5bff750f","updated":"2022-10-19 16:41:12.000000000","message":"Thanks for the quick responses! I realized that i should have modified things a bit more as the point would be to have\n\n_(non-client) library *feature* freeze at Milestone-2_\n\nand not the final release obviously. That maybe soften a bit the tone, sorry for that o:)","commit_id":"644b85af0337f8d39d3a966765da9ac74ea90219"}]}