)]}'
{"resolutions/20180301-stable-branch-eol.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"18a390a180d9dfc7a159386ea08f92136ec5b313","unresolved":false,"context_lines":[{"line_number":33,"context_line":"   the scope of this resolution, but it typically means no one is maintaining"},{"line_number":34,"context_line":"   the branch, it is not tested and fixes cannot merge."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_414ccdc6","line":36,"range":{"start_line":36,"start_character":3,"end_line":36,"end_character":27},"updated":"2018-03-01 11:32:27.000000000","message":"The current [...]\n\nmight be a little easier to parse","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f86911e7460e34f14923360f6ca9347a941689bc","unresolved":false,"context_lines":[{"line_number":33,"context_line":"   the scope of this resolution, but it typically means no one is maintaining"},{"line_number":34,"context_line":"   the branch, it is not tested and fixes cannot merge."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_2b5f13e3","line":36,"range":{"start_line":36,"start_character":3,"end_line":36,"end_character":27},"in_reply_to":"1f9dbf25_414ccdc6","updated":"2018-03-01 21:29:36.000000000","message":"Yeah will update.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"56e7c46ce091ca6b303fd3e7a37e746119381f9e","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_436933bc","line":38,"range":{"start_line":38,"start_character":45,"end_line":38,"end_character":50},"updated":"2018-03-06 13:20:38.000000000","message":"We probably want to use the same $series-eol tag format for this? We\u0027ll have to make sure reno doesn\u0027t get confused if both the branch and tag exist, but I think since it looks for the branch first we should be OK.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"cbb12b0efe1599350fc4378ab1decd25144fd64f","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_f04e18c0","line":38,"range":{"start_line":38,"start_character":45,"end_line":38,"end_character":50},"in_reply_to":"df7087c5_22668fef","updated":"2018-03-07 15:50:54.000000000","message":"Maybe just -em ?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":13629,"name":"Zhipeng","email":"huangzhipeng@huawei.com","username":"zhipengh"},"change_message_id":"0b4b817622a1cebdc8e99ff1d8aa0e067669e5ad","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_22668fef","line":38,"range":{"start_line":38,"start_character":45,"end_line":38,"end_character":50},"in_reply_to":"df7087c5_d90c7344","updated":"2018-03-07 08:47:44.000000000","message":"+1 to -eom","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"f13e7c4a3da63f51be158530de2ec718c006005a","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_ff4edcbf","line":38,"range":{"start_line":38,"start_character":45,"end_line":38,"end_character":50},"in_reply_to":"df7087c5_f04e18c0","updated":"2018-03-07 23:03:13.000000000","message":"I like that. That would probably be a better fit with what we are calling it.\n\nThen we could also tag -eom further down the road if/when we want to indicate the extended maintenance period is over.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_d90c7344","line":38,"range":{"start_line":38,"start_character":45,"end_line":38,"end_character":50},"in_reply_to":"ff6b8bd7_436933bc","updated":"2018-03-06 23:58:49.000000000","message":"I\u0027m not sure -eol would be the right thing. Maybe -eom? I would only be concerned about us irreversibly labelling something as end of life, when after that death it could still see a lot of updates and activity if other parties are willing to put the time in to update it.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d2be55cc02eb3ca8da1d279106f673335e9e8236","unresolved":false,"context_lines":[{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"#. Releases"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_d7e0b399","line":40,"range":{"start_line":39,"start_character":17,"end_line":40,"end_character":44},"updated":"2018-03-05 16:16:14.000000000","message":"please note this statement for the discussions happening below for the \u0027Testing\u0027 policies...\n\nCould you please also clarify the semantical difference for \u0027no longer supported\u0027, when this statement is applied to the \u0027follows-policy\u0027 projects vs not applied (out of the resolution scope) for non following projects?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"#. Releases"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_df2f58f4","line":40,"range":{"start_line":39,"start_character":17,"end_line":40,"end_character":44},"in_reply_to":"df7087c5_2270cf72","updated":"2018-03-07 23:26:21.000000000","message":"Given the swift assertions below, then this likely becomes:\n\n\"indicating it may no longer be managed by the upstream stable branch...\"\n\nBecause some projects might still have stable branch cores that manage these older -em branches (I likely would in nova if people proposed patches). But it\u0027s no guarantee that the core team managing the \"supported\" 18 month branch is also going to be doing that for the -em branches.\n\nThe flip side to that would be, if a project like swift plans on not changing anything in how they manage stable branches and the core teams for said stable branches, then they likely don\u0027t need to apply the -em tag, maybe until such a time that test infrastructure degrades to the point that integration tests (tempest) can\u0027t be run on the branch.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"017e4a2173b998ae04660a05d35eb48bc93a4edf","unresolved":false,"context_lines":[{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"#. Releases"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_d93bf699","line":40,"range":{"start_line":39,"start_character":17,"end_line":40,"end_character":44},"in_reply_to":"ff6b8bd7_43ae13e8","updated":"2018-03-06 14:35:09.000000000","message":"+1","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"56e7c46ce091ca6b303fd3e7a37e746119381f9e","unresolved":false,"context_lines":[{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"#. Releases"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_43ae13e8","line":40,"range":{"start_line":39,"start_character":17,"end_line":40,"end_character":44},"in_reply_to":"ff6b8bd7_d7e0b399","updated":"2018-03-06 13:20:38.000000000","message":"We talked about not using the term \"support\" when talking about these branches to avoid appearing to be doing more than we really are. Maybe \"no longer managed by\" would be better wording?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":13629,"name":"Zhipeng","email":"huangzhipeng@huawei.com","username":"zhipengh"},"change_message_id":"0b4b817622a1cebdc8e99ff1d8aa0e067669e5ad","unresolved":false,"context_lines":[{"line_number":36,"context_line":"   What is today the normal end of life process of apply the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"   tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"   change to not delete the branch. However, a tag will be applied on the"},{"line_number":39,"context_line":"   final release indicating it is no longer supported by the upstream stable"},{"line_number":40,"context_line":"   branch maintenance (and associated) teams."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"#. Releases"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_2270cf72","line":40,"range":{"start_line":39,"start_character":17,"end_line":40,"end_character":44},"in_reply_to":"ff6b8bd7_d93bf699","updated":"2018-03-07 08:47:44.000000000","message":"+1","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"18a390a180d9dfc7a159386ea08f92136ec5b313","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_e1c63917","line":49,"updated":"2018-03-01 11:32:27.000000000","message":"+1","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d2be55cc02eb3ca8da1d279106f673335e9e8236","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_b7c89f74","line":49,"in_reply_to":"1f9dbf25_e1c63917","updated":"2018-03-05 16:16:14.000000000","message":"+1 it looks like a very nice and natural summary of the long running discussions, specifically https://etherpad.openstack.org/p/LTS-proposal","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"017e4a2173b998ae04660a05d35eb48bc93a4edf","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_f9befafd","line":49,"in_reply_to":"ff6b8bd7_4397f391","updated":"2018-03-06 14:35:09.000000000","message":"Hmm, we almost need 3 categories then. Official upstream maintenance (18 months, with point releases), extended upstream maintenance (same core team, can still release), and extended downstream maintenance (other team, no more release).","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_5c9a91c5","line":49,"in_reply_to":"ff6b8bd7_85218850","updated":"2018-03-06 23:58:49.000000000","message":"The more we can simplify things the better. Just not too simple.\n\nWith how automated release activities are now, I think it is fine to continue to do releases for older branches. I don\u0027t think that would be a significant extra load on the release team.\n\nI would want to continue with requiring PTL or release liaison +1 for these. Even if the current core team is less actively involved in the older branches, they should be aware and OK with allowing new releases if the release will continue to go under the projects name.\n\nI do agree with notmyname though - I am a little leery of allowing a different set of people take over an older branch of a project. That does seem like a fork to me, as he pointed out at the PTG.\n\nI think it would be good to have another group with rights that can be explicitly added, but I think the existing project maintainers need to continue to have some control over things. Or at the least the ability to maintain control, whether they choose to exercise that ability or not.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"56e7c46ce091ca6b303fd3e7a37e746119381f9e","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_4397f391","line":49,"in_reply_to":"ff6b8bd7_b7c89f74","updated":"2018-03-06 13:20:38.000000000","message":"I thought last week we reversed this, and said releases would be OK because the original project teams were still going to be involved. IIRC, someone thought some distros only use tagged releases.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_3f553451","line":49,"in_reply_to":"ff6b8bd7_df7193e2","updated":"2018-03-07 23:26:21.000000000","message":"\u003e I propose we still require the PTL to +1 release requests. That way\n \u003e the upstream team still keeps control on what\u0027s released under\n \u003e their project name. It\u0027s flexible and avoids making 3 categories.\n\nThis then puts the burden on the upstream maintainer to have to review what the \u0027other downstream team\u0027 has been doing, which goes against part of the benefit of handing things over - the upstream teams want to move on since maintaining an infinitely long number of stable branches isn\u0027t sustainable, but at the same time, \u0027downstream\u0027 people from different orgs want a common place to hack on these older -em branches. We use the release as an indication of upstream support, which we\u0027re letting go after 18 months.\n\nOtherwise we\u0027re just back to square one and I might as well have just proposed, \"openstack will no longer end-of-life branches unless they degrade to the point that patches can\u0027t be tested or merged, and releases will not happen after some point (no more integration testing?)\".","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"e15e7fb1e8e9187afe009ef2e4218a76e7f8e822","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_85218850","line":49,"in_reply_to":"ff6b8bd7_df7193e2","updated":"2018-03-06 18:42:52.000000000","message":"Having the PTL or liaison sign off on the release, just as we do now, seems reasonable.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"624054fa67f9a72eb65b11459536e2eeb7b5c08b","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_df7193e2","line":49,"in_reply_to":"ff6b8bd7_f4ab5f72","updated":"2018-03-06 17:40:45.000000000","message":"I propose we still require the PTL to +1 release requests. That way the upstream team still keeps control on what\u0027s released under their project name. It\u0027s flexible and avoids making 3 categories.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_ff47bcbb","line":49,"in_reply_to":"ff6b8bd7_f9befafd","updated":"2018-03-07 23:26:21.000000000","message":"\u003e Hmm, we almost need 3 categories then. Official upstream\n \u003e maintenance (18 months, with point releases), extended upstream\n \u003e maintenance (same core team, can still release), and extended\n \u003e downstream maintenance (other team, no more release).\n\nWhat\u0027s the difference between the first two categories? Same core team doing releases...is the same thing.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"ef5ff2c797140708fd404299a65d2f6c5a8b4fe3","unresolved":false,"context_lines":[{"line_number":46,"context_line":"   branch in OpenStack. After that, there will be no releases as a release"},{"line_number":47,"context_line":"   would indicate support from the upstream teams, which is not going to be"},{"line_number":48,"context_line":"   the case. Contributors can continue to push fixes and they can be merged"},{"line_number":49,"context_line":"   but they will not be released upstream."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_f4ab5f72","line":49,"in_reply_to":"ff6b8bd7_f9befafd","updated":"2018-03-06 15:20:39.000000000","message":"I think I\u0027m starting to agree with notmyname that we don\u0027t want completely disconnected teams doing that work. If that\u0027s the case, I see no reason to stop producing releases based on a hard cut-off policy. Or even to add the -eol tags.\n\nLet\u0027s try adjusting the existing policy to make it simpler and to reduce work, without adding any more new rules than we need to accomplish that.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d2be55cc02eb3ca8da1d279106f673335e9e8236","unresolved":false,"context_lines":[{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_f793775b","line":54,"range":{"start_line":54,"start_character":6,"end_line":54,"end_character":66},"updated":"2018-03-05 16:16:14.000000000","message":"ditto, fits into https://etherpad.openstack.org/p/LTS-proposal very well, so +1 from me.\nAnd that \u0027...if they (old cores) still want to work on it, great\u0027 works as well.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f2f6f5cf4d0f06561828fe628e2370f009595bdf","unresolved":false,"context_lines":[{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_6933e3ac","line":54,"range":{"start_line":54,"start_character":6,"end_line":54,"end_character":66},"in_reply_to":"df7087c5_c6dc5e76","updated":"2018-03-08 16:59:33.000000000","message":"I think we\u0027re now saying that we aren\u0027t going to have different stable branch core teams for EM and non-EM branches. If people are doing good work on the EM stable branches, then they likely should be included in the regular stable branch maint team for the project.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"change_message_id":"9c34b7bea69821bdfd6cc1fae6c393de9af6b3d1","unresolved":false,"context_lines":[{"line_number":51,"context_line":"#. Core team"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_c6dc5e76","line":54,"range":{"start_line":54,"start_character":6,"end_line":54,"end_character":66},"in_reply_to":"ff6b8bd7_f793775b","updated":"2018-03-08 16:21:06.000000000","message":"One question on this - will we ask that the stable-maint-core team approve these people as well (i.e. will the people that sign up to take an non upstream maintained branch have to build up a history of consistent stable reviews)?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":330,"name":"John Dickinson","email":"me@not.mn","username":"notmyname"},"change_message_id":"1345003771ec011bc66f4d0d6fe09e45164d4fce","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_610d493d","line":56,"updated":"2018-03-01 11:48:24.000000000","message":"I oppose this one part. The core team should still be responsible for maintaining older branches, at their discretion, and responsibility should not be turned over to a different team.\n\nIf a team separate from the existing core team is maintaining an older release, anything that maintenance team is producing should not be named the same thing as the thing the core team is producing.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"a53c0eb8893fe603ad9d55103330d7d9d6dcfb3a","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_ebf60b90","line":56,"in_reply_to":"1f9dbf25_0b5a57f2","updated":"2018-03-01 21:43:11.000000000","message":"Also, I don\u0027t expect the existing stable branch core team to just be removed from core for these \u0027extended maintenance\u0027 branches after the 18 month upstream support window, since if they still want to work on it, great. But it means the rules change about who can be on the core team, which means basically anyone willing to work on it. That is essentially what happens internally at a company when we end of life a branch upstream anyway - the people doing support internally have to be core on their internal version of the branch. This is just providing an opportunity for people from different companies doing the same thing to do it together upstream.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"57ac3c7eed1eb7deb68d4887a564ff661225b669","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_fcc6dc16","line":56,"in_reply_to":"1f9dbf25_610d493d","updated":"2018-03-01 12:19:27.000000000","message":"As I recall the reasoning for this is that the core team is already over tasked and asking them to have oversight really-old-stuff is not something that can happen, so this provides a way for other people to say \"okay, we\u0027ll care for it\".\n\nIf we require that master cores care for it, then we are saying that the current status quo can work and that doesn\u0027t appear to be the case.\n\nIt would be _great_ if there were sufficient people, time, energy for everyone to be able to spread themselves, but that doesn\u0027t seem to acknowledge (a potentially lame, but it\u0027s the one we\u0027ve got) reality.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2592b5de1e53dbb686de8ed5a143c6db2ad45376","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_d54f1790","line":56,"in_reply_to":"1f9dbf25_7fa5c203","updated":"2018-03-03 09:07:31.000000000","message":"I assume people consuming code from stable branches are going to be confused if we don\u0027t have a general rule here on timeline, otherwise every project is just going to do it\u0027s own thing and I\u0027ve always heard that is too confusing for consumers. If the wild west confusion only kicks in after 18 months, then maybe that\u0027s fine.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"56e7c46ce091ca6b303fd3e7a37e746119381f9e","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_43737381","line":56,"in_reply_to":"1f9dbf25_d54f1790","updated":"2018-03-06 13:20:38.000000000","message":"IIRC, last week we agreed to drop this provision and leave the existing per-project stable teams as owners of the branches with information about which versions are actively being maintained published using the releases.o.o site.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":1955,"name":"Alan Pevec","email":"alan.pevec@redhat.com","username":"apevec"},"change_message_id":"7784ab11f0b1193c4b6ca38b4a5334c8f7aac346","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_7fa5c203","line":56,"in_reply_to":"1f9dbf25_f40a7024","updated":"2018-03-03 00:21:00.000000000","message":"If project\u0027s core team is willing to provide \"extended maintenance\" on their own, that\u0027s good and should be respected. Only if they are not willing, \"EM\" core team can be added to the branch ACL.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"e0d63a3b05772bce8390990b09b5576c6aabb29b","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_f40a7024","line":56,"in_reply_to":"1f9dbf25_fcc6dc16","updated":"2018-03-02 10:28:13.000000000","message":"I think the key word for interpreting this part is the use of \"typically\" to describe the 18 months in \"Releases\".  In the event that an upstream core team wishes to provide support for a different amount of time, I do not believe the current wording interferes with being \"atypical\" (e.g. being willing to continuously support things for arbitrarily long).  That said, atypical projects may need to be closely involved in the teams listed in the beginning of this document over the entire span of support if there is to be any expectation that other teams are willing to support the atypical behaviour.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f86911e7460e34f14923360f6ca9347a941689bc","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_0b5a57f2","line":56,"in_reply_to":"1f9dbf25_fcc6dc16","updated":"2018-03-01 21:29:36.000000000","message":"What Chris said. We can\u0027t have our cake and eat it too, both for the upstream stable branch maintainers and the downstream people that want to keep these branches around forever. I can\u0027t speak to experience for what maintaining stable branches is like for swift, as I\u0027ve never been involved there since swift is pretty isolated in this regard compared to the rest of the projects in openstack. I don\u0027t know if that means there can be exclusions to this resolution and swift becomes the exception.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_dfc2f8e9","line":56,"in_reply_to":"df7087c5_3cd0fd50","updated":"2018-03-07 23:26:21.000000000","message":"OK so to summarize, no more separate core teams. We should just never EOL branches unless we can\u0027t land code on them. Then all of the downstream consumers are happy, the vendors supporting older branches are happy, and the only ones not happy and left with the burden are the people already doing the work upstream - but they can just start to drop off and claim the -em tag and stop doing releases (and the QA team can move forward with making breaking changes to Tempest).","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_dff4385e","line":56,"in_reply_to":"ff6b8bd7_43737381","updated":"2018-03-07 23:26:21.000000000","message":"\u003e IIRC, last week we agreed to drop this provision and leave the\n \u003e existing per-project stable teams as owners of the branches with\n \u003e information about which versions are actively being maintained\n \u003e published using the releases.o.o site.\n\nI don\u0027t know where that agreement happened - in the TC room at the PTG? There were a lot of people that are involved in aspects of stable branch policy that weren\u0027t in that room for that discussion.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"017e4a2173b998ae04660a05d35eb48bc93a4edf","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_b9d2c233","line":56,"in_reply_to":"ff6b8bd7_43737381","updated":"2018-03-06 14:35:09.000000000","message":"We suggested that any team wanting to continue maintenance should engage with the core team before doing so, if only so that they can be integrated in the upstream stable maint team instead. There is still the open question of what happens if some group wants to continue to maintain a branch that the upstream project team wants to kill. Should the maintenance takeover be denied ?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_3cd0fd50","line":56,"in_reply_to":"ff6b8bd7_9488e31f","updated":"2018-03-06 23:58:49.000000000","message":"This is a good point - I think we need to publish the (perceived?) state of some of these older branches on releases.o.o or similar. That can be a follow up exercise, but it would be good to come up with some sort of classification for older project\u0027s branches to help give an idea of their actual maintenance state, and not just their age.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"5821f64cf4654e14c0de44b9de214fae9f56515c","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   After the upstream support phase ends, the core team for the branch will"},{"line_number":54,"context_line":"   be turned over to essentially whoever is maintaining the branch."},{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_9488e31f","line":56,"in_reply_to":"ff6b8bd7_b9d2c233","updated":"2018-03-06 15:17:44.000000000","message":"How likely do we think it is that a team made up of no regular contributors to the project is going to be able to keep a very old branch running without any help from the regular contributors?\n\nI thought we were looking for a way to change our existing policy to encourage more people to help, and that one important thing we identified as blocking people from joining the existing stable teams is that it\u0027s not useful to do so because the stable team is only looking at branches those people haven\u0027t even upgraded to, yet. Removing the hard dates around EOL should mean that as people do come around wanting to work on branches, they *can* because the branches still exist (whether they *will* help beyond proposing fixes is still out of our control).\n\nWe can continue to publish information about which branches are actually being maintained for each project so that consumers understand that older branches are not good candidates for new deployments. We need to do that for each project, not for the branches as a whole, because I expect some projects to be maintained for longer than others. The higher up the stack a project sits, the more likely it is that someone could deploy a new version even if they\u0027re using an old version of something lower in the stack, for example.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2592b5de1e53dbb686de8ed5a143c6db2ad45376","unresolved":false,"context_lines":[{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"   The stable branches will continue to run the same level of CI testing after"},{"line_number":61,"context_line":"   the standard 18 month window, as long as feasible. Tempest is branchless"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_b5312b0e","line":58,"updated":"2018-03-03 09:07:31.000000000","message":"Another thing I forgot to mention here is that if one project were to go EOL and others depend on it, then devstack ceases to work (like when neutron/cinder/keystone go EOL before nova). But if we don\u0027t EOL the branch, this isn\u0027t a problem.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"66e3f370d33155d8ab13ec9c1931c53520891174","unresolved":false,"context_lines":[{"line_number":55,"context_line":"   Maintenance includes, but is not limited to, backporting fixes, reviewing"},{"line_number":56,"context_line":"   proposed patches, and fixing infra/CI issues."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"#. Testing"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"   The stable branches will continue to run the same level of CI testing after"},{"line_number":61,"context_line":"   the standard 18 month window, as long as feasible. Tempest is branchless"}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_bd129557","line":58,"in_reply_to":"1f9dbf25_b5312b0e","updated":"2018-03-08 19:40:28.000000000","message":"Nevermind, this was resolved in devstack-gate with change:\n\nI1b2d030df8cb2a850bf9248595171d96a813d381\n\nNova needed that to land stable/newton patches after other projects like cinder/keystone/neutron had already deleted stable/newton and created newton-eol.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"e0d63a3b05772bce8390990b09b5576c6aabb29b","unresolved":false,"context_lines":[{"line_number":61,"context_line":"   the standard 18 month window, as long as feasible. Tempest is branchless"},{"line_number":62,"context_line":"   and has historically dropped support for testing older branches once they"},{"line_number":63,"context_line":"   are end of life. This allows Tempest (and devstack) to drop compatibility"},{"line_number":64,"context_line":"   code and other technical debt. After the 18 month support window when"},{"line_number":65,"context_line":"   maintenance duties are turned over to other interested parties, the QA team"},{"line_number":66,"context_line":"   *can* move forward with changes that disrupt an old branch if those changes"},{"line_number":67,"context_line":"   cannot be easily made another way. This resolution will not attempt to"},{"line_number":68,"context_line":"   predict or codify what those types of changes might be, or how maintenance"},{"line_number":69,"context_line":"   on older branches can be extended and still run integration tests with"},{"line_number":70,"context_line":"   Tempest. The point is the QA team can move forward and not be hindered by"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_37277ab6","line":67,"range":{"start_line":64,"start_character":34,"end_line":67,"end_character":37},"updated":"2018-03-02 10:28:13.000000000","message":"I would prefer \"may\" to \"can\".  Also, it may be useful to define \"easily\" in a way that leaves the decision to the team managing the repository.\n\nMore generally, in the case where such breaking changes are introduced, interested parties should be able to branch from that breakpoint, if they wish to maintain such a branch (e.g. for ThirdParty CI, shared downstream validation, etc.).","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2592b5de1e53dbb686de8ed5a143c6db2ad45376","unresolved":false,"context_lines":[{"line_number":61,"context_line":"   the standard 18 month window, as long as feasible. Tempest is branchless"},{"line_number":62,"context_line":"   and has historically dropped support for testing older branches once they"},{"line_number":63,"context_line":"   are end of life. This allows Tempest (and devstack) to drop compatibility"},{"line_number":64,"context_line":"   code and other technical debt. After the 18 month support window when"},{"line_number":65,"context_line":"   maintenance duties are turned over to other interested parties, the QA team"},{"line_number":66,"context_line":"   *can* move forward with changes that disrupt an old branch if those changes"},{"line_number":67,"context_line":"   cannot be easily made another way. This resolution will not attempt to"},{"line_number":68,"context_line":"   predict or codify what those types of changes might be, or how maintenance"},{"line_number":69,"context_line":"   on older branches can be extended and still run integration tests with"},{"line_number":70,"context_line":"   Tempest. The point is the QA team can move forward and not be hindered by"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_3560bb01","line":67,"range":{"start_line":64,"start_character":34,"end_line":67,"end_character":37},"in_reply_to":"1f9dbf25_37277ab6","updated":"2018-03-03 09:07:31.000000000","message":"I\u0027m OK with s/can/may/.\n\nI don\u0027t know how the QA team would feel about branching Tempest, at least in the official repo. If someone wanted to fork and branch Tempest and then run CI from the forked branch, that\u0027s up to them.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"e0d63a3b05772bce8390990b09b5576c6aabb29b","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   the maintenance of the stable branches after the upstream teams have turned"},{"line_number":72,"context_line":"   over that work."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In other words, these older branches might, at some point, just be running"},{"line_number":75,"context_line":"   pep8 and unit tests."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_7752e215","line":75,"range":{"start_line":74,"start_character":3,"end_line":75,"end_character":23},"updated":"2018-03-02 10:28:13.000000000","message":"This paragraph seems extraneous to me, especially if there are sensible desired breaking changes in the pep8 suite, or the supporting teams wish not to run some unit tests as some features are no longer supported even by them.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d2be55cc02eb3ca8da1d279106f673335e9e8236","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   the maintenance of the stable branches after the upstream teams have turned"},{"line_number":72,"context_line":"   over that work."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In other words, these older branches might, at some point, just be running"},{"line_number":75,"context_line":"   pep8 and unit tests."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_f7261717","line":75,"range":{"start_line":74,"start_character":3,"end_line":75,"end_character":23},"in_reply_to":"1f9dbf25_753ba3ea","updated":"2018-03-05 16:16:14.000000000","message":"...pep8 and unit tests and/or a 3rd party CI jobs maintained by vendors represented in the core teams.\n\nnit: Could you please add that?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2592b5de1e53dbb686de8ed5a143c6db2ad45376","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   the maintenance of the stable branches after the upstream teams have turned"},{"line_number":72,"context_line":"   over that work."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In other words, these older branches might, at some point, just be running"},{"line_number":75,"context_line":"   pep8 and unit tests."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_753ba3ea","line":75,"range":{"start_line":74,"start_character":3,"end_line":75,"end_character":23},"in_reply_to":"1f9dbf25_7752e215","updated":"2018-03-03 09:07:31.000000000","message":"My point is to try and say that these older branches might not get devstack/tempest integration testing, but only what they can test - which might at some point be pep8/py27 at a most.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   the maintenance of the stable branches after the upstream teams have turned"},{"line_number":72,"context_line":"   over that work."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In other words, these older branches might, at some point, just be running"},{"line_number":75,"context_line":"   pep8 and unit tests."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_1f56302b","line":75,"range":{"start_line":74,"start_character":3,"end_line":75,"end_character":23},"in_reply_to":"df7087c5_7c3bd59b","updated":"2018-03-07 23:26:21.000000000","message":"I think we want tempest running on patches as long as possible, but at some point the QA team needs to be able to cut bait and make breaking changes to the oldest branches.\n\nI don\u0027t know what a 3rd party CI system would be running if it\u0027s running integration tests. It couldn\u0027t be using master Tempest if Tempest makes breaking changes which makes us stop running it on the branch upstream. That would then likely mean the 3rd party CI has created an internal tempest repo with a branch based on some Tempest tag. Maybe that\u0027s OK, I know it\u0027s something we had to do when I was working on IBM\u0027s OpenStack distro and we supported branches that were EOL upstream.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":71,"context_line":"   the maintenance of the stable branches after the upstream teams have turned"},{"line_number":72,"context_line":"   over that work."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"   In other words, these older branches might, at some point, just be running"},{"line_number":75,"context_line":"   pep8 and unit tests."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_7c3bd59b","line":75,"range":{"start_line":74,"start_character":3,"end_line":75,"end_character":23},"in_reply_to":"ff6b8bd7_f7261717","updated":"2018-03-06 23:58:49.000000000","message":"Yeah, might be good to mention vendors may choose to run third party CI against these and report results. Not that there\u0027s any reason to stop them, but good to state clearly that that is acceptable and probably a good thing to do for those that really care about these.\n\nI\u0027ve also been told from at least one vendor in relation to the driverfixes branches that they at least need passing unit tests in order for that code to be of any use to them. We might want to commit to just running pep8 and unit tests.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"change_message_id":"8329826b0751ccd822ddeb00845a2de24dca999b","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_1377e4d6","line":79,"range":{"start_line":79,"start_character":38,"end_line":79,"end_character":47},"updated":"2018-03-02 14:09:45.000000000","message":"\"Generally\" seems a little loose for me - I think we should be more explicit, and use \"MUST\".","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d2be55cc02eb3ca8da1d279106f673335e9e8236","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_d772f311","line":79,"range":{"start_line":79,"start_character":38,"end_line":79,"end_character":47},"in_reply_to":"1f9dbf25_1377e4d6","updated":"2018-03-05 16:16:14.000000000","message":"-1 IMO a strict MUST would not work for vendors who strive to backport features or medium bugfixes. Why shall we prohibit what brings prolly the most value for vendors singed to maintain things instead of the official openstack teams?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2592b5de1e53dbb686de8ed5a143c6db2ad45376","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_953e6fd8","line":79,"range":{"start_line":79,"start_character":38,"end_line":79,"end_character":47},"in_reply_to":"1f9dbf25_1377e4d6","updated":"2018-03-03 09:07:31.000000000","message":"That works for me.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_ff2d7ca8","line":79,"range":{"start_line":79,"start_character":38,"end_line":79,"end_character":47},"in_reply_to":"df7087c5_5c5ff1e4","updated":"2018-03-07 23:26:21.000000000","message":"What Sean said, which I think implies -2 to backporting features since those features won\u0027t be allowed on the \"upstream managed\" stable branches either.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"1206b038b600f5ac88cf1fd29120c325a6779ea7","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_fda7cd4e","line":79,"range":{"start_line":79,"start_character":38,"end_line":79,"end_character":47},"in_reply_to":"ff6b8bd7_d772f311","updated":"2018-03-06 09:30:05.000000000","message":"\u003e MUST would not work for vendors who strive to backport features\n\nI think I went into enough details last time on why feature backports are no-go here.. TL;DR: it will make upgrade LTS-\u003enon-LTS have feature regressions.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_5c5ff1e4","line":79,"range":{"start_line":79,"start_character":38,"end_line":79,"end_character":47},"in_reply_to":"ff6b8bd7_fda7cd4e","updated":"2018-03-06 23:58:49.000000000","message":"I think we MUST enforce that fixes will go through merging to master \u003e n-1 \u003e n-2, etc. Making changes to older branches without making sure later branches have those changes is in effect forking them.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":13629,"name":"Zhipeng","email":"huangzhipeng@huawei.com","username":"zhipengh"},"change_message_id":"0b4b817622a1cebdc8e99ff1d8aa0e067669e5ad","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_026cab34","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":55},"updated":"2018-03-07 08:47:44.000000000","message":"Do we need additional words on the requirement for the documentation of any fixes introduced into the em tagged branches ? something like these crtitical fixes should not be ported without appropriate documentions.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"e0d63a3b05772bce8390990b09b5576c6aabb29b","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_37753a96","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"updated":"2018-03-02 10:28:13.000000000","message":"It may be useful to add a paragraph beneath this one discussing the possibility of branches with other policies, if desired, as the policy of what can be published is one of the many points of contention in this discussion (and multiple branches solves that nicely, as long as they are accompanied by multiple teams offering support).","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d2be55cc02eb3ca8da1d279106f673335e9e8236","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_f754d756","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"1f9dbf25_37753a96","updated":"2018-03-05 16:16:14.000000000","message":"\u003e possibility of branches with other policies\n\n+1 to that proposal, see also my comment wrt \u0027MUST\u0027 vs \u0027should\u0027.\n\n\n\u003e I\u0027m not sure we should support that upstream\n\ngiven that\n\u0027...it is no longer supported by the upstream stable branch maintenance (and associated) teams\u0027 that seems like a conflicting statement. We should not sign off supporting something (releases) and apply strict policies to that at once. At least in the same resolution :D","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2592b5de1e53dbb686de8ed5a143c6db2ad45376","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_d51dd773","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"1f9dbf25_37753a96","updated":"2018-03-03 09:07:31.000000000","message":"I\u0027m not sure we should support that upstream - if someone wants to fork the repo and branch then that\u0027s on them.\n\nUnless you\u0027re alluding to something like the cinder driverfixes branch.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"a46db71ce541bb0820a8b50ffeefa3f4c499f2de","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_90abdd87","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"1f9dbf25_d51dd773","updated":"2018-03-03 11:12:04.000000000","message":"I was thinking something more like the various linux collaborative \"supported\" repos (ignoring vendor trees).  There are four, as follows:\n\nA) Mainline.  Bugfix work is typically wrapped into the next release.\nB) \"LTS\": selected bugfixes are backported for a period of time\nC) \"LTSI\": selected bugfixes are backported and new features are merged (whether submitted to mainline or not)\nD) \"SLTS\": selected bugfixes are backported, with occasional forward rebasing on mainline, while preserving ABI and API stability.\n\n    These are four very different policies.  All four have different communities providing support.  All four are hosted by kernel.org, and each has multiple vendor trees that derive from them.  My preference would be for OpenStack to have a policy that allowed that, assuming a sufficient demonstration of interest on the part of maintainers for each branch.\n\n    I believe the way to get there would be to have a framework resolution that is not intended to change that permits the existence of branches that are supported on different than default timeframes, and then a set of resolutions (from none to many) with specific policies attached to specific branch naming schemes, to be supported by specific volunteers, with the expectation that those volunteers (ideally including some or all of the core reviewers for each project) would otherwise confirm to openstack social expectations.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"81d3d62f2611932f5bdfa7eb947c88edfc27e610","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_c95f8f3f","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"df7087c5_09ab4789","updated":"2018-03-08 17:12:53.000000000","message":"Actually after discussing with fungi, this came up at the PTG and people thought we could drop phase 3. Thinking about it more, phase 3 is really about tightening up the branch before it\u0027s EOL because we don\u0027t want to risk backporting something that we later found out causes a regression and then the branch goes EOL and we can\u0027t fix the regression. With EM branches, we don\u0027t have as much risk for that happening, so it\u0027s justifiable to just drop phase 3 support and extend phase 2.\n\nSo I think that leaves us with:\n\n* phase 1: 6 months + releases\n* phase 2: 1 year + releases\n* EM: no releases","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f2f6f5cf4d0f06561828fe628e2370f009595bdf","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_09ab4789","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"df7087c5_26275ab6","updated":"2018-03-08 16:59:33.000000000","message":"It would be:\n\n* I   Latest release (6 months long) (released)\n* II  Maintained release (6 months long) (released)\n* III Legacy release (6 months long) (released)\n* EM (same fix criteria as phase II, not released)","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"b3da6a191d708dfc4e17da48ee4187ee84068b0d","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_fe6260d8","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_9d4b3186","updated":"2018-03-06 13:50:57.000000000","message":"\u003e giving new names, like nova-redhat, for example.\n\nI very much believe new names are useful.  I don\u0027t think this is a good example name, as vendor trees properly belong downstream.  The examples I provided from the linux community are all active collaborations from multiple vendors, and used as source for downstream trees.  OpenStack may not yet be large enough to need this sort of thing.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"56e7c46ce091ca6b303fd3e7a37e746119381f9e","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_c3bb03e3","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_9d4b3186","updated":"2018-03-06 13:20:38.000000000","message":"As I said last week, we don\u0027t need to give people permission to fork and do their own thing. We only need to describe what we\u0027re agreeing to do together as part of the community.\n\nWe talked about relaxing the existing stable policy to drop phase III (in which only security fixes are allowed), effectively extending the phase II policy for the lifetime of the branch. That may not be sufficient for all consumers, but it\u0027s an incremental improvement over what we have now.\n\nI do not like the idea of different policies being applied to different projects or to different branches in an arbitrary way, because that makes consuming the branches in a \"safe\" manner more confusing.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"b3da6a191d708dfc4e17da48ee4187ee84068b0d","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_9ed00453","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_c3bb03e3","updated":"2018-03-06 13:50:57.000000000","message":"\u003e I do not like the idea of different policies being applied to\n \u003e different projects or to different branches in an arbitrary way,\n \u003e because that makes consuming the branches in a \"safe\" manner more\n \u003e confusing.\n\nI share your dislike for arbitrary arrangements.  I only advocate for leaving the possibility for future statements that would permit specifically named sets of branches with specifically identified policies, such that one shared agreed policy would apply to any branches that belong to a given set.  While my preference for extended release consists of \"maintain feature and ABI stability\", there are strong arguments for only \"maintain ABI stability\", and I have yet to see any compromise between these positions that is workable to both groups.  \n\nA key component of my position is that there should only be sets of branches with policy where there is an identified group of folk who are going to use them for collaboration.  To my mind, simply offering freedom to fork encourages people to do so, which leads either to the current practice of several vendor branches sharing patches in ways that are invisible upstream or to proliferation of alternate \"upstream\" sources depending on the consuming community (where the \"upstream\" for a set of consumers may be entirely unrelated to the repositories on git.openstack.org).","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"4d79cfaea22f04101bcda74f126c1c438dbd5f78","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_26275ab6","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_c3bb03e3","updated":"2018-03-08 16:21:16.000000000","message":"\u003e We talked about relaxing the existing stable policy to drop phase\n \u003e III (in which only security fixes are allowed), effectively\n \u003e extending the phase II policy for the lifetime of the branch. That\n \u003e may not be sufficient for all consumers, but it\u0027s an incremental\n \u003e improvement over what we have now.\n\nMaybe it\u0027s just me, but I\u0027m a bit confused now, how are the new Support phases look like. Originally, according to _stable branch maintenance guide_, the phases were:\n* I   Latest release (6 months long)\n* II  Maintained release (6 months long)\n* III Legacy release (6? months long)\n\nSo will the phases be like:\n* I   Latest release (6 months long)\n* II  Maintained release (12 months long)\n* -em (extended maintenance) phase (until it is maintained by someone)\n\nShouldn\u0027t this doc mention these phases somewhere?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_5a3836d2","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_f754d756","updated":"2018-03-07 23:26:21.000000000","message":"\u003e given that\n \u003e \u0027...it is no longer supported by the upstream stable branch\n \u003e maintenance (and associated) teams\u0027 that seems like a conflicting\n \u003e statement. We should not sign off supporting something (releases)\n \u003e and apply strict policies to that at once. At least in the same\n \u003e resolution :D\n\nThis is a good point. I don\u0027t think the upstream teams can drop off and also be expected to enforce policy.\n\nIt sounds like many people are shifting to the idea of the existing teams continuing to support these older branches, with similar policies as we already have for what\u0027s appropriate. If you want a feature branch based on newton at this point, you need to create it yourself, it\u0027s not going to be maintained/released by the upstream teams and we should consider it a fork.\n\nThis also ties back into the idea of not releasing these -em branches after a certain point; if we\u0027re going to relax the policy rules on what gets merged there, then we need to not release them under openstack. It\u0027s fine to have a place to collaborate on fixes but we shouldn\u0027t release them after our normal global 18 month period is over.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"1206b038b600f5ac88cf1fd29120c325a6779ea7","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_9d4b3186","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_f754d756","updated":"2018-03-06 09:30:05.000000000","message":"\u003e possibility of branches with other policies\n\nAs long as we clearly dissociate them from the original projects, sure. Which means not hosting them in the openstack and ideally giving new names, like nova-redhat, for example.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":76,"context_line":""},{"line_number":77,"context_line":"#. Appropriate fixes"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"   Backports to these branches should generally follow the upstream"},{"line_number":80,"context_line":"   `stable branch maintenance guide`_. This means critical (data loss, major"},{"line_number":81,"context_line":"   impact to upgrades) and security fixes, not features."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_fc6fe58f","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":56},"in_reply_to":"ff6b8bd7_fe6260d8","updated":"2018-03-06 23:58:49.000000000","message":"I agree with Doug here.\n\nIt should also be noted that with using microversions, the idea of allow features to be backported becomes untenable in most cases. You can\u0027t just backport a new feature that requires microversion 3.55 without also pulling along changes for 3.1 - 3.54.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":10343,"name":"Jim Rollenhagen","email":"jim@jimrollenhagen.com","username":"jimrollenhagen"},"change_message_id":"3ab94933f00d99d9860365b76647002bf0cae61c","unresolved":false,"context_lines":[{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"   This resolution applies only to projects that have the"},{"line_number":86,"context_line":"   `stable:follows-policy tag`_. The reason being those projects have not"},{"line_number":87,"context_line":"   committed to or demonstrated an ability to follow the upstream stable"},{"line_number":88,"context_line":"   branch maintenance guide with respect to appropriate fixes, e.g. they may"},{"line_number":89,"context_line":"   support backporting features."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_2ec71c15","line":86,"updated":"2018-03-02 10:14:11.000000000","message":"s/those/other/ ? The projects with the tag have demonstrated the ability, right?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac839c729478ef42829dfd2148f783f7c16bd665","unresolved":false,"context_lines":[{"line_number":83,"context_line":"#. Applicable projects"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"   This resolution applies only to projects that have the"},{"line_number":86,"context_line":"   `stable:follows-policy tag`_. The reason being those projects have not"},{"line_number":87,"context_line":"   committed to or demonstrated an ability to follow the upstream stable"},{"line_number":88,"context_line":"   branch maintenance guide with respect to appropriate fixes, e.g. they may"},{"line_number":89,"context_line":"   support backporting features."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f9dbf25_b0f619f9","line":86,"in_reply_to":"1f9dbf25_2ec71c15","updated":"2018-03-03 10:14:35.000000000","message":"Yup my mistake.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"56e7c46ce091ca6b303fd3e7a37e746119381f9e","unresolved":false,"context_lines":[{"line_number":86,"context_line":"   `stable:follows-policy tag`_. The reason being those projects have not"},{"line_number":87,"context_line":"   committed to or demonstrated an ability to follow the upstream stable"},{"line_number":88,"context_line":"   branch maintenance guide with respect to appropriate fixes, e.g. they may"},{"line_number":89,"context_line":"   support backporting features."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"   .. todo:: Caveat here is deployment projects like TripleO - what about them?"},{"line_number":92,"context_line":"             Also, if those projects don\u0027t support upstream stable branch"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ff6b8bd7_4394d344","line":89,"updated":"2018-03-06 13:20:38.000000000","message":"Do we want a new tag for projects that also follow this policy? Or is this a redefinition of that existing tag and its associated policy?","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"46e8154636f1b45e9a1bb11d269818f2397e62c1","unresolved":false,"context_lines":[{"line_number":86,"context_line":"   `stable:follows-policy tag`_. The reason being those projects have not"},{"line_number":87,"context_line":"   committed to or demonstrated an ability to follow the upstream stable"},{"line_number":88,"context_line":"   branch maintenance guide with respect to appropriate fixes, e.g. they may"},{"line_number":89,"context_line":"   support backporting features."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"   .. todo:: Caveat here is deployment projects like TripleO - what about them?"},{"line_number":92,"context_line":"             Also, if those projects don\u0027t support upstream stable branch"}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_fa490a60","line":89,"in_reply_to":"df7087c5_dc20e14c","updated":"2018-03-07 23:26:21.000000000","message":"Having thought about this some more, I\u0027m not sure we should even mention anything about the stable:follows-policy tag. I don\u0027t think anyone looks at it, or maintains it, or makes sure it\u0027s up to date with all of the various projects. The only person that would is the stable PTL and it\u0027s a huge pain in the ass (I tried doing it when the tag was first added and it\u0027s not fun).\n\nPlus it basically means, projects that follow the rules within the normal support window are now doing this other thing, but for projects that never followed the rules anyway, they are already doing what they want, so who cares.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"141aabf75f8a4d1ee097a91d8ef547c0afbf53e9","unresolved":false,"context_lines":[{"line_number":86,"context_line":"   `stable:follows-policy tag`_. The reason being those projects have not"},{"line_number":87,"context_line":"   committed to or demonstrated an ability to follow the upstream stable"},{"line_number":88,"context_line":"   branch maintenance guide with respect to appropriate fixes, e.g. they may"},{"line_number":89,"context_line":"   support backporting features."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"   .. todo:: Caveat here is deployment projects like TripleO - what about them?"},{"line_number":92,"context_line":"             Also, if those projects don\u0027t support upstream stable branch"}],"source_content_type":"text/x-rst","patch_set":1,"id":"df7087c5_dc20e14c","line":89,"in_reply_to":"ff6b8bd7_4394d344","updated":"2018-03-06 23:58:49.000000000","message":"I think I would feel a little more comfortable with a stable:follows-extended-policy tag.","commit_id":"116dc2183d76b91b8afb297f8c6abbb2cd2c5186"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"db2fb2d4aa2f14c6a8a995c416cd0905f5ae9181","unresolved":false,"context_lines":[{"line_number":23,"context_line":"use cases, caveats, etc - it would never end. The purpose of this resolution"},{"line_number":24,"context_line":"is to summarize and state the stance of the various upstream stable branch"},{"line_number":25,"context_line":"maintainers and related teams (mentioned above) with respect to extended"},{"line_number":26,"context_line":"maintenance windows for stable branches and their end of life process."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"End of life"},{"line_number":29,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_6ff3de9f","line":26,"updated":"2018-03-08 22:44:47.000000000","message":"We should mention up here near the top that the first series this change would apply to is Ocata.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f322b2216a49a47031ed1bfdc40d9a1eae1d529","unresolved":false,"context_lines":[{"line_number":23,"context_line":"use cases, caveats, etc - it would never end. The purpose of this resolution"},{"line_number":24,"context_line":"is to summarize and state the stance of the various upstream stable branch"},{"line_number":25,"context_line":"maintainers and related teams (mentioned above) with respect to extended"},{"line_number":26,"context_line":"maintenance windows for stable branches and their end of life process."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"End of life"},{"line_number":29,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_a2690dbf","line":26,"in_reply_to":"df7087c5_6ff3de9f","updated":"2018-03-08 23:23:14.000000000","message":"Sure I can do that after some more replies trickle in over night.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"e1228ee4958c5d1c2c464636190a8c1b7c994dc6","unresolved":false,"context_lines":[{"line_number":34,"context_line":"the branch, it is not tested and fixes cannot merge."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"The current end of life process of applying the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"change to not delete the branch. Instead, a ``\u003cbranch\u003e-em`` tag will be"},{"line_number":39,"context_line":"applied on the final release indicating the branch is now in"},{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_a737d6b0","line":38,"range":{"start_line":37,"start_character":69,"end_line":38,"end_character":31},"updated":"2018-03-09 10:12:50.000000000","message":"Would it be better to say the EOL process is being superseded by the EM process until the branch is no longer maintained, at which point we then apply the current EOL process, deleting the branch etc?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f24445a980b2d5fef10f5e658076552a0a58a5cf","unresolved":false,"context_lines":[{"line_number":34,"context_line":"the branch, it is not tested and fixes cannot merge."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"The current end of life process of applying the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"change to not delete the branch. Instead, a ``\u003cbranch\u003e-em`` tag will be"},{"line_number":39,"context_line":"applied on the final release indicating the branch is now in"},{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_ad49f08b","line":38,"range":{"start_line":37,"start_character":69,"end_line":38,"end_character":31},"in_reply_to":"df7087c5_9b3eabd8","updated":"2018-03-09 15:11:48.000000000","message":"I can change to that but we need to decide what to say about the discussion below, about whether or not we reserve the right to *ever* EOL a branch even if no one is maintaining it and it\u0027s broken and can\u0027t land patches.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"4b230cf2cb090a82169b859f3e92f4ad523a27a8","unresolved":false,"context_lines":[{"line_number":34,"context_line":"the branch, it is not tested and fixes cannot merge."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"The current end of life process of applying the ``\u003cbranch\u003e-eol``"},{"line_number":37,"context_line":"tag and deleting the branch, cleaning up related infra scripts, etc, will"},{"line_number":38,"context_line":"change to not delete the branch. Instead, a ``\u003cbranch\u003e-em`` tag will be"},{"line_number":39,"context_line":"applied on the final release indicating the branch is now in"},{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_9b3eabd8","line":38,"range":{"start_line":37,"start_character":69,"end_line":38,"end_character":31},"in_reply_to":"df7087c5_a737d6b0","updated":"2018-03-09 13:12:46.000000000","message":"I would simplify by just saying \"At the end of the stable maint team official maintenance window, we would no longer EOL the branch. Instead...\"","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"c9f60c21ae7aedff20a8b1a3c9d7e8a5a8cc3a10","unresolved":false,"context_lines":[{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"If at some point fixes cannot land in a given project and there is no"},{"line_number":43,"context_line":"reasonable solution, then the branch will need to be EOL for that project."},{"line_number":44,"context_line":"Note that it is possible for our CI infrastructure to `function based on EOL"},{"line_number":45,"context_line":"tags`_."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_421fd16b","line":43,"range":{"start_line":43,"start_character":26,"end_line":43,"end_character":56},"updated":"2018-03-09 00:35:36.000000000","message":"So at this point we would tag $series-eol and remove the branch? or in the new world doe EOL\u0027ing mean something different?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f24445a980b2d5fef10f5e658076552a0a58a5cf","unresolved":false,"context_lines":[{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"If at some point fixes cannot land in a given project and there is no"},{"line_number":43,"context_line":"reasonable solution, then the branch will need to be EOL for that project."},{"line_number":44,"context_line":"Note that it is possible for our CI infrastructure to `function based on EOL"},{"line_number":45,"context_line":"tags`_."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_cdf0e46a","line":43,"range":{"start_line":43,"start_character":26,"end_line":43,"end_character":56},"in_reply_to":"df7087c5_16c5925b","updated":"2018-03-09 15:11:48.000000000","message":"I intended the same as what Lee said above. Iff the branch for a project cannot merge code and solving that is not reasonable and no one is working on it, then we EOL and delete the branch. I don\u0027t see what point there would be in leaving it around broken forever except as a dumping ground for people to push patches that can\u0027t land. I intentionally didn\u0027t get into what \u0027reasonable solutions\u0027 meant, or what the criteria for \u0027how long it\u0027s broken and no one is trying to fix it\u0027 is, since that\u0027s likely something we\u0027d just know once it becomes an actual problem.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c8f149fb38969c85736bd67ed855be9cdc1365ef","unresolved":false,"context_lines":[{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"If at some point fixes cannot land in a given project and there is no"},{"line_number":43,"context_line":"reasonable solution, then the branch will need to be EOL for that project."},{"line_number":44,"context_line":"Note that it is possible for our CI infrastructure to `function based on EOL"},{"line_number":45,"context_line":"tags`_."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_9af9a04e","line":43,"range":{"start_line":43,"start_character":26,"end_line":43,"end_character":56},"in_reply_to":"df7087c5_2fd630f3","updated":"2018-03-12 10:58:39.000000000","message":"Deleting the branch when it gets annoying having it around seems sensible. It is nice extra messaging on its status.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"e1228ee4958c5d1c2c464636190a8c1b7c994dc6","unresolved":false,"context_lines":[{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"If at some point fixes cannot land in a given project and there is no"},{"line_number":43,"context_line":"reasonable solution, then the branch will need to be EOL for that project."},{"line_number":44,"context_line":"Note that it is possible for our CI infrastructure to `function based on EOL"},{"line_number":45,"context_line":"tags`_."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_67f3fe0b","line":43,"range":{"start_line":43,"start_character":26,"end_line":43,"end_character":56},"in_reply_to":"df7087c5_421fd16b","updated":"2018-03-09 10:12:50.000000000","message":"AFAICT the eventual EOL process would stay the same.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"65327057471d50ce70aebbb3c9dd5050d9d96d0e","unresolved":false,"context_lines":[{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"If at some point fixes cannot land in a given project and there is no"},{"line_number":43,"context_line":"reasonable solution, then the branch will need to be EOL for that project."},{"line_number":44,"context_line":"Note that it is possible for our CI infrastructure to `function based on EOL"},{"line_number":45,"context_line":"tags`_."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_16c5925b","line":43,"range":{"start_line":43,"start_character":26,"end_line":43,"end_character":56},"in_reply_to":"df7087c5_67f3fe0b","updated":"2018-03-09 13:32:11.000000000","message":"I think we want to stop deleting branches completely. I\u0027m anticipating interest in branches lagging somewhat, so after a branch is considered \"broken\" we may have people show up with enough interest to try and fix it.\n\nIf we think updating the README.txt or a STATUS.txt file within the repo to either state the status or link to releases.o.o for the status is not sufficient to let people know that we consider a branch EOL, then a tag seems OK. But let\u0027s just stop doing all of the extra work involved in deleting branches.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"04aad458a08378882014d1403035fd613144e7aa","unresolved":false,"context_lines":[{"line_number":40,"context_line":"*extended maintenance (EM)* mode."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"If at some point fixes cannot land in a given project and there is no"},{"line_number":43,"context_line":"reasonable solution, then the branch will need to be EOL for that project."},{"line_number":44,"context_line":"Note that it is possible for our CI infrastructure to `function based on EOL"},{"line_number":45,"context_line":"tags`_."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_2fd630f3","line":43,"range":{"start_line":43,"start_character":26,"end_line":43,"end_character":56},"in_reply_to":"df7087c5_cdf0e46a","updated":"2018-03-09 19:34:04.000000000","message":"OK, I guess I can go along with that. I don\u0027t know how many patches we would really find proposed to these older branches but if we end up deleting something someone later wants we can deal with that at the time.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"c9f60c21ae7aedff20a8b1a3c9d7e8a5a8cc3a10","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_259bc7c9","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"updated":"2018-03-09 00:35:36.000000000","message":"I\u0027m happy to go with this for now as it\u0027s a step in the direction that people are asking for and less work for the stable team :) but there was some discussion of dropping Phase II as well and just signalling via the releases repo when a given branch/project combo would transition into EM.\n\nReally not trying to bikeshed but Could we make it :\n\n* Phase I: 12 months + releases\n* Phase II: 6 months + releases\n\nI\u0027m mindful of operators in the room in Sydney that stated they found bugs in newton that were painful enough for them to patch but didn\u0027t classify as critical and so even if the branch was open they\u0027d still need a private back port","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"65327057471d50ce70aebbb3c9dd5050d9d96d0e","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_76e72ee6","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_16183273","updated":"2018-03-09 13:32:11.000000000","message":"I thought we had discussed doing away with phases entirely and just having the current phase I policy apply for the lifetime of the branch. Maybe I misremembered or misunderstood the outcome of that discussion, though.\n\nIn any case, if we don\u0027t include the phase information in the resolution then we are going to need to update the project team guide page quickly because I expect that will be the first question everyone reading this asks.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"eebfa8411d0a910c7d060825dc14f67d2474e061","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_3bbd28b7","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_259bc7c9","updated":"2018-03-09 03:11:35.000000000","message":"I like the idea of extending phase I support.\n\nI\u0027m not sure we need to finalize this point for this change to land though. It probably is good if we have agreement, but the details of stable phases seem like something we can tweak as we go and shouldn\u0027t be something that ends up slowing down this overall resolution.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"d5215f8670f57be88361629406ea68abf72830a8","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_ea4fd3ba","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_259bc7c9","updated":"2018-03-09 10:20:26.000000000","message":"I\u0027m in favour of dropping phase II entirely and having a single support phase for stable but agree this can be discussed elsewhere.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"04aad458a08378882014d1403035fd613144e7aa","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_cf1454a3","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_39a8c275","updated":"2018-03-09 19:34:04.000000000","message":"\u003e * non-EM (first 18 months) and\n \u003e * EM (everything after)\n \u003e \n \u003e works for me.\n \u003e \n \u003e (I was just confused / curious, because on PTG it was mentioned\n \u003e that Stable maint will be *longer* and I couldn\u0027t see how: 18\n \u003e months was before (phase I+II+III) and it will be 18 months from\n \u003e now on as well (non-EM). So I didn\u0027t know how it was meant then)\n\nI\u0027m not sure we said the stable maintenance period would be longer. We\u0027re going to use the same stable *branches* for the EM period, though, so maybe that\u0027s what you mean?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"616d9301777a739ddfe7ac5378e1511e5dc67db9","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_78762fa7","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_39a8c275","updated":"2018-03-09 23:59:56.000000000","message":"Phase III is *at most* 6 months now and often 0, so with this we are extending it to 18 months it\u0027s just confusing how ;P","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f24445a980b2d5fef10f5e658076552a0a58a5cf","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_ada2504a","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_76e72ee6","updated":"2018-03-09 15:11:48.000000000","message":"I put the phase stuff in here because someone explicitly asked for it in PS1 of the review. As ttx suggests, I could just remove it and distinguish everything in here as non-EM (first 18 months) and EM (everything after). And then punt the discussion about the phases for non-EM vs EM to a later date.\n\nIt\u0027s hard to strike a balance in here between getting something that can move forward and also answering peoples (many, many) questions about the detailed policy.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"616d9301777a739ddfe7ac5378e1511e5dc67db9","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_7884ef5e","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_76e72ee6","updated":"2018-03-09 23:59:56.000000000","message":"Nope you\u0027re remembering correctly that was my proposal.  we keep the existing definition of \"acceptable fixes\" and just have that extend to the life-cycle of the stable branch (regardless of pre-EM or post -EM).  That maps to Phase I for ever :)","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"389b13b4592abcc72af0b4ae2dd94d7bbf678385","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_1c71c70c","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_7a2feca0","updated":"2018-03-14 13:17:53.000000000","message":"I can remove the specific phase stuff from this resolution. I\u0027ll just say that any changes to the support phases will happen separately in the stable branch guidelines.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c8f149fb38969c85736bd67ed855be9cdc1365ef","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_7a2feca0","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_989ea3b6","updated":"2018-03-12 10:58:39.000000000","message":"Given resolutions are ideally never edited, I lean towards not including the details here.\n\nMaybe just reference that stable policy needs to be refreshed to take non-EM to EM transition into account. Maybe could provide an example of what is being proposed, so as to make it clear this doc isn\u0027t the definitive guide of the policy?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"9fbbdf52c36794578ef97d9b2e7df8a75acf43d8","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_39a8c275","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_ada2504a","updated":"2018-03-09 17:31:50.000000000","message":"* non-EM (first 18 months) and\n* EM (everything after)\n\nworks for me.\n\n(I was just confused / curious, because on PTG it was mentioned that Stable maint will be *longer* and I couldn\u0027t see how: 18 months was before (phase I+II+III) and it will be 18 months from now on as well (non-EM). So I didn\u0027t know how it was meant then)","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"04aad458a08378882014d1403035fd613144e7aa","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_2fef10b1","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_ada2504a","updated":"2018-03-09 19:34:04.000000000","message":"\u003e I put the phase stuff in here because someone explicitly asked for\n \u003e it in PS1 of the review. As ttx suggests, I could just remove it\n \u003e and distinguish everything in here as non-EM (first 18 months) and\n \u003e EM (everything after). And then punt the discussion about the\n \u003e phases for non-EM vs EM to a later date.\n \u003e \n \u003e It\u0027s hard to strike a balance in here between getting something\n \u003e that can move forward and also answering peoples (many, many)\n \u003e questions about the detailed policy.\n\nI feel like we\u0027re on the cusp of having this ready to approve. I\u0027m voting +1 on this version. I would like to resolve the exact stable policy question very shortly, though.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"616d9301777a739ddfe7ac5378e1511e5dc67db9","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_989ea3b6","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_ada2504a","updated":"2018-03-09 23:59:56.000000000","message":"I know this was added because of issues on PS1 but I think it\u0027s wrong to codify the implementation in the resolution and that should be moved to a review of the stable-policy (which is what I said in the TC room at the PTG).\n\nBut I\u0027d also like to make a decision / vote soon","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"616d9301777a739ddfe7ac5378e1511e5dc67db9","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_5881eb49","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_cf1454a3","updated":"2018-03-09 23:59:56.000000000","message":"In the Tuesday session we did imply that stable \"support\" would be push back to 18 months which is longer than the current 12 +(optional) 6.\n\nI don\u0027t recall that being explicitly mentioned in the TC room","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"4b230cf2cb090a82169b859f3e92f4ad523a27a8","unresolved":false,"context_lines":[{"line_number":65,"context_line":"The traditional `support phases`_ will change to:"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_16183273","line":68,"range":{"start_line":68,"start_character":0,"end_line":68,"end_character":29},"in_reply_to":"df7087c5_ea4fd3ba","updated":"2018-03-09 13:12:46.000000000","message":"Yes I would keep the Phase I \u0026 II completely out of this document, just say that there is a period (currently 18 months) of stable maint team official maintenance window (or minimal maintenance window) with releases, and then EM without releases. That way we can redefine Phases in the stable branch policy without needing painful resolution amending.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"3a6c2b74d8d38aa4116e3590cdf1bd3af5fa7026","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_0fefc284","line":69,"updated":"2018-03-08 23:00:42.000000000","message":"For example, we\u0027ve been discussing that the VMT will likely document that security fix support for branches under extended maintenance is \"best-effort\" and we, for example, may not hold up embargoes/announcements waiting for patches to be backported to them so as to avoid unnecessarily degrading the security of our newer stable branches still under active upstream maintenance. Ceasing to tag point releases there may help to make that situation more obvious.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"4ba58fed9873bace597d6c05a63e53af63eab2d3","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_efffee64","line":69,"updated":"2018-03-08 22:44:59.000000000","message":"Just wondering if there could be some sort of time based release (quarterly or whatever) so that folks don\u0027t have to rely on hashes when trying to consume this branch?  If it\u0027s time based perhaps it could just be automated to reduce the requirement on individuals having to prep/do things.  We\u0027d also get an automated notice when things start breaking and perhaps it\u0027s time to retire it.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"53a76f5786802ac3323962c962d7408fcd36b91c","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_32ea1875","line":69,"updated":"2018-03-09 21:55:24.000000000","message":"What we\u0027d been hearing is that various distros wanted a place to collaborate on patches to older OpenStack releases. The idea was that by keeping these branches open we give them a place to do that, without any implication that the OpenStack teams responsible for the corresponding software are necessarily blessing new point releases of ancient versions. It provides a place for interested parties to propose, review and agree on backported fixes which they can then cherry-pick into their own trees for consistency, rather than having to do that via more ad hoc means and possibly having additional iterations to achieve consitency across distributions for a given patch (or perhaps even never achieving that).","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"45df1444173cbb8bc9e19351e007400a026e9a4d","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_91e9991b","line":69,"updated":"2018-03-10 18:34:12.000000000","message":"You don\u0027t even need the convoluted git-archive dance... pbr makes `setup.py sdist` (or bdist_wheel) generate a monotonically-versioned package for you.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"92ff52c60b97666aa95ea7a5b1cfdd3ce71ec7f6","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_af5fb63f","line":69,"in_reply_to":"df7087c5_0fefc284","updated":"2018-03-08 23:14:08.000000000","message":"My feeling is that most current downstreams who are actively maintaining branches well past the current EOL timeframe (whether self-supported or vendor-supported) already have a set of patches in their trees, and are best served by adding additional changes on an as-needed basis on a schedule aligned with their operational or business concerns, rather than any calendric schedule.  The EM branch provides a convenient central coordination point for such patches, but should not be considered a replacement for active downstream maintenance.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"3730acddc7792aa383d685c10714aff5bb73b134","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_6c8668de","line":69,"in_reply_to":"df7087c5_186ff392","updated":"2018-03-11 00:06:45.000000000","message":"\u003e Or is the\n \u003e fact the tarball didn\u0027t from tarballs.o.o and aren\u0027t signed more of\n \u003e a problem than I understand?\n\nIf there are no signed tarballs, the consumption may continue to just be cherry picks of patches to the downstream. Which may or may not be clean so could just end up being more of a pain.  And may further introduce issues if the downstream misses a patch or whatever. It\u0027s much easier if there are tarballs and we can just rebase the differences on a regular basis.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"8d510469beb277b3f3e1d76c0cba277103d05b0e","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_b50292b3","line":69,"in_reply_to":"df7087c5_32ea1875","updated":"2018-03-09 22:44:53.000000000","message":"I\u0027m not sure what the point of proposing the patches if you aren\u0027t going to be able to consume them in a similar fashion. Just posting the patches doesn\u0027t really help out with their consumption because you\u0027ll either have to consume them all or you\u0027ll be carrying whatever differences there are between what you\u0027re downstream tree looks like and the upstream. If you can continue to post checkpoints then it allows the downstream consumers a way of being able to agree/move towards unified maintenance.  My concern is that if my base and your base aren\u0027t the same (ie a stable hash/tag/whatever), our patches will look different upstream/downstream which just increases the maintenance cost rather than really being a benefit.  There are many people who would look to that and say why bother because I\u0027m going to have to manually merge all the patches downstream anyway so why should I propose it upstream if the patch is going to be completely different because my tree doesn\u0027t look like yours.  As a downstream consumer we rely on the tarballs as starting point so if they aren\u0027t going to exist for our consumption, it might not matter if this process exists upstream because we\u0027ll just have to pick all the patches from upstream and carry them downstream anyway. The proposed process just adds more items the downstream will have to sync some how if they choose to propose things upstream.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"9397ecf86becea84dc9b9dfa1e95d2907b66757d","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_f98d6a31","line":69,"in_reply_to":"df7087c5_40a33b9f","updated":"2018-03-09 17:28:58.000000000","message":"Could you expand on how you are expecting to consume these branches?  My naive expectation was that the several downstreams would be carrying various patches (as is done currently), and would be cherry-picking additional changes from the EM branch.  For at least a couple of consumption policies with which I am familiar, pulling a new tarball would not be permitted.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"616d9301777a739ddfe7ac5378e1511e5dc67db9","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_186ff392","line":69,"in_reply_to":"df7087c5_8f7e5c69","updated":"2018-03-09 23:59:56.000000000","message":"I understand what you\u0027re saying here but I disagree.  It\u0027s pretty trivial to run something like:\n\n cd openstack/nova \u0026\u0026 git archive --prefix \"nova-$(git describe HEAD^ --abbrev\u003d0)/\" stable/newton  \u003e ../nova-$(git describe HEAD^ --abbrev\u003d0).tar.gz\n\nand unless the specific patches were totally inappropriate for upstream it\u0027s possible that you wont need to carry them.  Or is the fact the tarball didn\u0027t from tarballs.o.o and aren\u0027t signed more of a problem than I understand?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f322b2216a49a47031ed1bfdc40d9a1eae1d529","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_c23d21bc","line":69,"in_reply_to":"df7087c5_af5fb63f","updated":"2018-03-08 23:23:14.000000000","message":"Agree with Doug, Jeremy and Emmet. Doing releases isn\u0027t a technical problem, it\u0027s a signaling/social problem.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"616d9301777a739ddfe7ac5378e1511e5dc67db9","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_d8fdfbb1","line":69,"in_reply_to":"df7087c5_b50292b3","updated":"2018-03-09 23:59:56.000000000","message":"I understand what you\u0027re saying in the context of say newton something that\u0027s already been EOL\u0027d, but how to the 2 trees get so divergent for say ocata which still has the place in the community to work togther?   Hmm I s\u0027pose with the Phase II/III defn\u0027s I can see how tress would diverge.\n\nSo lets consider this from a queens+ perspective ... can you help me (us?) understand how 2 vendors end up with such divergent trees if there has *always* been a place to collaborate?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"3fcbe40a21cc0a6e60b09a23076121c41b5a012c","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_35ea0275","line":69,"in_reply_to":"df7087c5_b50292b3","updated":"2018-03-09 23:15:20.000000000","message":"Something to remember about Extended Maintenance branches is that they are an alternative to deleting the branch entirely upstream.  I do not read anything into this resolution that either forces particular downstreams to participate or implies that every patch must be consumed by any downstream that is unable to upgrade to match the release cycle.  My understanding of the intent is to provide a place to enable those downstreams that wish to collaborate using the openstack infrastructure to do so.  If a particular downstream would find this process onerous, the easy alternative is to continue with the status quo, simply not consuming changes from upstream more than 18 months after release.\n\nIf there is consensus by several downstreams participating in this process for specific branches and specific release timing, it may be appropriate for them to collectively prepare tarballs or similar as a collaborative downstream activity.  I do not believe this should need to involve the existing release team (or affect existing release policy), and doubt that it makes sense to discuss this possibility in much depth prior to reaching agreement to have branches not deleted long enough that the character of such branches can be evaluated.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"13e5ea39af7e6d71462cf0ec4c8b1c927f14831c","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_40a33b9f","line":69,"in_reply_to":"df7087c5_c23d21bc","updated":"2018-03-09 15:32:49.000000000","message":"Yea I was just thinking of the consumption of these patches. I know from my experience we can import from a specific hash to a certain degree but it\u0027s much easier if it\u0027s a specific tag w/ a tarball.  If we\u0027re going to leave it open, that\u0027s fine but making it a bit friendly to consume would be beneficial to consumers.  I\u0027m not sure the signaling folks are talking about is necessarily a good thing.  You can signal without going silent...","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"0d89134ca7a2cec6c742c93e3937c5fd4ce33b39","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_a7081bd9","line":69,"in_reply_to":"df7087c5_cc769407","updated":"2018-03-11 03:03:42.000000000","message":"I don\u0027t think anything here should be read as \"we\u0027re washing our hands\".  Personally, I applaud the restraint in this document, limiting constraints on implementation.  Most of the implementation details properly belongs to the stable maintenance policy, and the remainder likely to whoever decides to work on these branches.  Having the TC decide such things a priori just increases the effort required by developers to fix the details of the policy implementation later.  I suspect that after this resolution is approved, there will continue to be discussions and conversations about how things work, and that we shall eventually reach consensus once we\u0027ve done things for a while.  Until we actually try, it is very hard to guess what we will need.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":12898,"name":"Tony Breeds","email":"tony@bakeyournoodle.com","username":"tonyb"},"change_message_id":"e6319612418b3c13feff9f6331848dc05439c875","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_63fbae78","line":69,"in_reply_to":"df7087c5_cc769407","updated":"2018-03-14 03:28:30.000000000","message":"Okay.  I guess I can see how that would happen.  I don\u0027t really think this makes that any worse in the near term but it does makes some things better.  We\u0027ll certainly continue to explore ways we can improve the situation.\n\nIf we remove this list of phases then I think we have enough direction to go and solve the immediate problems without needed to undo parts of a resolution when we find reality didn\u0027t match the theory.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"3730acddc7792aa383d685c10714aff5bb73b134","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_cc769407","line":69,"in_reply_to":"df7087c5_d8fdfbb1","updated":"2018-03-11 00:06:45.000000000","message":"\u003e So lets consider this from a queens+ perspective ... can you help\n \u003e me (us?) understand how 2 vendors end up with such divergent trees\n \u003e if there has *always* been a place to collaborate?\n\nI\u0027ve run into issues where landing patches downstream (for reasons CVE or otherwise) in parallel to upstream (even for current branches) has resulted in pain when trying to clean up the branch when pulling in the latest version from upstream. And these aren\u0027t because patches are being landed because they won\u0027t be accepted upstream, they can be patches that land fine upstream but the ordering may introduce other side effects.\n\nAdditionally just because collaboration can occur upstream, doesn\u0027t mean that for some other reason it won\u0027t introduce issues when trying to sync the two.  I feel that just leaving it open isn\u0027t going to make collaboration occur and even if it does sometimes, it won\u0027t really help the consumption of the output from upstream.  I do still think there needs to be some sort of continued process rather than just leaving branches open.  We\u0027ve run into issues with that in puppet modules where the lack of tags just makes it hard to get to a usable point.  While you can manage it via hashes, it just makes it very hard to manage over time.\n\nAt this point I\u0027m sure this will land as is which is an improvement, but I\u0027d like to see some additional thought and attention given to these rather than everyone washing their hands of it and say \"but we left them open...\"","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"eb589c5621270393cd86d910a312977f187c4dc1","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_8f73d215","line":69,"in_reply_to":"df7087c5_efffee64","updated":"2018-03-08 22:51:55.000000000","message":"The point of stopping releases has less to do with the work involved (that is already largely automated) and more to do with signaling that the level of maintenance on those branches has changed.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"19ad0436c37680fc0a9b427b8890ab21fa11c6db","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Phase I: 6 months + releases"},{"line_number":68,"context_line":"* Phase II: 1 year + releases"},{"line_number":69,"context_line":"* Extended Maintenance: remainder of the life of the branch without releases"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"The traditional **Phase III** for stable branch maintenance will be dropped"},{"line_number":72,"context_line":"since its purpose was mostly to highly restrict applicable fixes to a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_8f7e5c69","line":69,"in_reply_to":"df7087c5_f98d6a31","updated":"2018-03-09 19:08:20.000000000","message":"So while many folks might be carrying patches, they may be carrying patches on top of an released tarballs.  For example if the packaging of puppet-aodh for 7.0.0, we would take http://tarballs.openstack.org/puppet-aodh/puppet-aodh-7.0.0.tar.gz and then apply our specific patches that we want to carry on top of this to give us 7.0.0-1 or 7.0.0-2, etc.  Continuing to have a branch open but no releases does not actually improve anyone\u0027s ability to consume these new patches because we\u0027d just have to carry the patches in downstream packaging and are not able to leverage them as a released bundle.  If we have an artifact (e.g. tarball), we would be able to rebase to an existing version and continue to carry any other patches we might need but would be able to drop the ones that exist upstream so we don\u0027t have to carry them in packaging anymore.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"1610930f1493d36a7c7f5909243885b0302c3370","unresolved":false,"context_lines":[{"line_number":87,"context_line":"----------"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"The stable branch core teams will remain unchanged between EM and non-EM"},{"line_number":90,"context_line":"branches. If people are doing good work on the EM stable branches, then"},{"line_number":91,"context_line":"they likely should be included in the regular stable branch core team for"},{"line_number":92,"context_line":"the project."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Testing"},{"line_number":95,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_18b70fd8","line":92,"range":{"start_line":90,"start_character":10,"end_line":92,"end_character":12},"updated":"2018-03-08 20:28:41.000000000","message":"Can we please let existing folks opt out of the responsibility being imposed on them?\n\n[15:24:18]  \u003cdims\u003e\tmriedem : so in the \"Core teams\" section ... some teams (at least some folks on some existing teams) do not want to pick up the burden. how do we handle that situation?\n[15:25:56]  \u003cmriedem\u003e\twell, they could eol the branch, but that\u0027s not good for the people that want it to live for longer\n[15:26:17]  \u003cmriedem\u003e\tthey could add people to the stable core team that actually do want to take up the maintenance\n[15:26:26]  \u003cmriedem\u003e\ti think the latter is probably the answer","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"4047aee9525b832f6136b775a83923a9f40f3889","unresolved":false,"context_lines":[{"line_number":87,"context_line":"----------"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"The stable branch core teams will remain unchanged between EM and non-EM"},{"line_number":90,"context_line":"branches. If people are doing good work on the EM stable branches, then"},{"line_number":91,"context_line":"they likely should be included in the regular stable branch core team for"},{"line_number":92,"context_line":"the project."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Testing"},{"line_number":95,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_381453a0","line":92,"range":{"start_line":90,"start_character":10,"end_line":92,"end_character":12},"in_reply_to":"df7087c5_18b70fd8","updated":"2018-03-08 20:35:08.000000000","message":"Do we need to formalise this opt-out?  As with any core team, I would expect different folk to have slightly different priorities.  When considering a stable branch core team, if some folk focus on more recent releases and others on older releases, this seems a sensible separation.  Are there existing stable branch maintenance teams who feel they are expected to prioritise EM reviews just because the branch exists?  Can they be disabused without formal language?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ed8aef6277782d93837b02dd8f80dc2584a45e36","unresolved":false,"context_lines":[{"line_number":87,"context_line":"----------"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"The stable branch core teams will remain unchanged between EM and non-EM"},{"line_number":90,"context_line":"branches. If people are doing good work on the EM stable branches, then"},{"line_number":91,"context_line":"they likely should be included in the regular stable branch core team for"},{"line_number":92,"context_line":"the project."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Testing"},{"line_number":95,"context_line":"-------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_984c7fc8","line":92,"range":{"start_line":90,"start_character":10,"end_line":92,"end_character":12},"in_reply_to":"df7087c5_381453a0","updated":"2018-03-08 20:41:45.000000000","message":"After reading what I have here, I\u0027m not sure we need to formalize it. As written, it implies that if you care about EM branches, then you get into the core team for the project by doing good review work on those and the regular stable core team (that doesn\u0027t want to focus on EM branches) adds you to the core team. The EM vs non-EM separation is then somewhat natural without needing to formalize something in here saying \"some projects can\u0027t keep up with existing stable branches let alone EM branches, so for those projects we\u0027ll have special rules\".","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"3223a3f069afc40920bea021ea8831215bc17150","unresolved":false,"context_lines":[{"line_number":107,"context_line":"codify what those types of changes might be, or how maintenance on older"},{"line_number":108,"context_line":"branches can be extended and still run integration tests with Tempest. The"},{"line_number":109,"context_line":"point is the QA team can move forward and not be hindered by the extended"},{"line_number":110,"context_line":"maintenance of the stable branches."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"In other words, these older branches might, at some point, just be running"},{"line_number":113,"context_line":"pep8 and unit tests but those are required at a minimum."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_af21f64f","line":110,"updated":"2018-03-08 22:30:47.000000000","message":"A technical question which won\u0027t block my support of this plan: Do we have a way for those branches to use a pinned version of tempest and/or devstack? Since tempest itself is branchless, we would need to pin to a version, right?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"0d312395c956087d5b2d76daa010fa4afbcedb9f","unresolved":false,"context_lines":[{"line_number":107,"context_line":"codify what those types of changes might be, or how maintenance on older"},{"line_number":108,"context_line":"branches can be extended and still run integration tests with Tempest. The"},{"line_number":109,"context_line":"point is the QA team can move forward and not be hindered by the extended"},{"line_number":110,"context_line":"maintenance of the stable branches."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"In other words, these older branches might, at some point, just be running"},{"line_number":113,"context_line":"pep8 and unit tests but those are required at a minimum."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_62bf75fb","line":110,"in_reply_to":"df7087c5_427b518b","updated":"2018-03-08 23:35:39.000000000","message":"OK, it sounds like we could solve this so I\u0027m happy waiting to pick the actual solution when it becomes a real issue.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f322b2216a49a47031ed1bfdc40d9a1eae1d529","unresolved":false,"context_lines":[{"line_number":107,"context_line":"codify what those types of changes might be, or how maintenance on older"},{"line_number":108,"context_line":"branches can be extended and still run integration tests with Tempest. The"},{"line_number":109,"context_line":"point is the QA team can move forward and not be hindered by the extended"},{"line_number":110,"context_line":"maintenance of the stable branches."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"In other words, these older branches might, at some point, just be running"},{"line_number":113,"context_line":"pep8 and unit tests but those are required at a minimum."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_427b518b","line":110,"in_reply_to":"df7087c5_4f361a06","updated":"2018-03-08 23:23:14.000000000","message":"devstack has branches, tempest doesn\u0027t, but tempest does (or used to) tag around release boundaries so that people have a reference point. As noted in PS1 review comments, that\u0027s what we\u0027d do at IBM when supporting EOL branches but still wanted to run Tempest on things we backported - we\u0027d create a branch on our internal Tempest repo based on the tag that most closely aligns with said EOL branch.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"92ff52c60b97666aa95ea7a5b1cfdd3ce71ec7f6","unresolved":false,"context_lines":[{"line_number":107,"context_line":"codify what those types of changes might be, or how maintenance on older"},{"line_number":108,"context_line":"branches can be extended and still run integration tests with Tempest. The"},{"line_number":109,"context_line":"point is the QA team can move forward and not be hindered by the extended"},{"line_number":110,"context_line":"maintenance of the stable branches."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"In other words, these older branches might, at some point, just be running"},{"line_number":113,"context_line":"pep8 and unit tests but those are required at a minimum."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_4f361a06","line":110,"in_reply_to":"df7087c5_af21f64f","updated":"2018-03-08 23:14:08.000000000","message":"I suggest \"no\", for the current resolution.  In the event there is active maintenance occuring, and some branch can no longer be tested, I believe we can answer this question better by involving the concerned parties at that time.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"82447c7156e1f1fe9392b8e70c0e07edb9f70ac6","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Appropriate fixes"},{"line_number":116,"context_line":"-----------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Backports to these branches must follow the upstream"},{"line_number":119,"context_line":"`stable branch maintenance guide`_. This includes but is not limited to:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* Bug fixes only. Features will not be accepted on stable branches."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_5867c74e","line":118,"updated":"2018-03-08 20:40:13.000000000","message":"Some folks want to just support specific releases and not others. Some folks want to backport things they feel they need even if they are not just bug fixes. Don\u0027t know how to get them to the table. Guess time will tell.\n\nAlso are these set of rules any different from the cinder driverfixes (taken as a precedent)?","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7236f1ffabaed5a10e103caa14463b107ca72c5b","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Appropriate fixes"},{"line_number":116,"context_line":"-----------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Backports to these branches must follow the upstream"},{"line_number":119,"context_line":"`stable branch maintenance guide`_. This includes but is not limited to:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* Bug fixes only. Features will not be accepted on stable branches."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_7892cbf8","line":118,"in_reply_to":"df7087c5_5867c74e","updated":"2018-03-08 20:47:32.000000000","message":"\u003e Some folks want to just support specific releases and not others.\n\nThen they should do that downstream. Upstream should not pick winners and losers for each branch that does or does not get EM support. Vendors/distributions that want special LTS rules will need to handle that on their own because one size does not fit all upstream.\n\n\u003e Some folks want to backport things they feel they need even if they are not just bug fixes.\n\nSame as above - they can do that downstream if they want, but the rule upstream is it\u0027s bug fixes only.\n\n\u003e Don\u0027t know how to get them to the table.\n\nI suspect that people that want those things are not going to get to the table no matter what we do upstream as they have their own internal special processes and likely want carte blanche and free support upstream regardless of the impact to the rest of the contributors and consumers. I am not interested in developing policies and procedures for those situations.\n\n\u003e Also are these set of rules any different from the cinder driverfixes (taken as a precedent)?\n\nI don\u0027t know what the rules are wrt cinder driverfixes branches. I thought they were basically (1) fixes are specific to storage backend drivers, not the main / core part of cinder and (2) bug fixes only.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"d76318f6c3e92fd2a4d78b848e60c1a46a16c8c9","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Appropriate fixes"},{"line_number":116,"context_line":"-----------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Backports to these branches must follow the upstream"},{"line_number":119,"context_line":"`stable branch maintenance guide`_. This includes but is not limited to:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* Bug fixes only. Features will not be accepted on stable branches."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_0fb022f4","line":118,"in_reply_to":"df7087c5_7892cbf8","updated":"2018-03-08 22:28:37.000000000","message":"+1 for all this.\n\nThat is correct about the driver fixes.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"3223a3f069afc40920bea021ea8831215bc17150","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Appropriate fixes"},{"line_number":116,"context_line":"-----------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Backports to these branches must follow the upstream"},{"line_number":119,"context_line":"`stable branch maintenance guide`_. This includes but is not limited to:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"* Bug fixes only. Features will not be accepted on stable branches."}],"source_content_type":"text/x-rst","patch_set":2,"id":"df7087c5_8f9bd270","line":118,"in_reply_to":"df7087c5_7892cbf8","updated":"2018-03-08 22:30:47.000000000","message":"\u003e \u003e Some folks want to just support specific releases and not others.\n \u003e \n \u003e Then they should do that downstream. Upstream should not pick\n \u003e winners and losers for each branch that does or does not get EM\n \u003e support. Vendors/distributions that want special LTS rules will\n \u003e need to handle that on their own because one size does not fit all\n \u003e upstream.\n\nIndividual contributors are always free to choose where they focus their time (at least to the degree their employer allows them). We don\u0027t want changes skipping over releases and causing problems with upgrades or \"donuts\" in the support of behavior over time, so we want them to patch things backwards one step at a time. They can stop at the branch they care about.\n\n \u003e \u003e Some folks want to backport things they feel they need even if\n \u003e they are not just bug fixes.\n \u003e \n \u003e Same as above - they can do that downstream if they want, but the\n \u003e rule upstream is it\u0027s bug fixes only.\n\nIf we actually find a bunch of people showing up to help with maintenance, I am willing to have a conversation about feature backports. But it is going to be very hard to do and maintain compatibility with microversions in the API, upgrade scripts, etc. so I don\u0027t really see it being accepted. A prerequisite for me even thinking more deeply about it though would be to have people actively working on these older branches.\n\n \u003e \u003e Also are these set of rules any different from the cinder\n \u003e driverfixes (taken as a precedent)?\n \u003e \n \u003e I don\u0027t know what the rules are wrt cinder driverfixes branches. I\n \u003e thought they were basically (1) fixes are specific to storage\n \u003e backend drivers, not the main / core part of cinder and (2) bug\n \u003e fixes only.\n\nMy understanding is that the driverfixes branch rules are more strict in the sense that only the drivers are supposed to be changed but at the same time they are more lenient in the sense that people can backport \"feature-like\" things such as adding support for newer hardware to the driver. We are just extending the normal phase II stable policy for more time with this change.","commit_id":"b5d358421b5e36354648dc84790e893e9754e35a"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"29a796d3f665d0ad4429ee5e83a3c50e8a4872f9","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_62da9a4b","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"updated":"2018-03-14 14:28:36.000000000","message":"I\u0027m having trouble understanding this point.  Are you saying:\n\nProject teams should not block proposed fixes for a branch based on non-technical aspects of the proposed patch.\n\nI guess \"technical merit\" is demonstrated by addressing all aspects of a bug appropriately, being a self-contained fix, having appropriate tests, etc.  What non-technical aspects are you thinking of here?  (It sounds to me like you may have a particular example in mind.)  Maybe this point could use a \"This means ...\" clause like you have in the previous point.","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"7757bee4de433a89e50f768eda525d86c38e89df","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_3f7cb81d","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_2d26d3cf","updated":"2018-03-14 16:21:06.000000000","message":"@Brian, consider a project that is essentially single-vendor driven (of which there are several in openstack). If that vendor decides they have their own downstream LTS policy that skips support for certain branches, they could hypothetically mirror that upstream and say, \"we\u0027ll take fixes on branch N-3 and N-1 but not N-2\". That\u0027s not a technical reason to not accept fixes on N-2, it\u0027s a social issue driven by the agenda of the vendor dominating that project.\n\nHaving said that, \"of the proposed branch\" should probably be \"of the proposed patch\" as you mentioned, maybe was just a typo in my original drafting of it.","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"3e29d1f6a345e3d661a08004b9bf40119f86551f","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_44440674","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_2d754afa","updated":"2018-03-16 11:23:00.000000000","message":"Thanks Matt,\n\nI wasn\u0027t expecting such from you anyways, I just wanted to bring in concrete example of case that this kind of fairly loose wording (and clearly misunderstanding from some of us of it\u0027s intention) could bring. The last thing the community needs is to fight off cases where something is already refused and gets reproposed as soon this resolution lands.\n\nI personally see the case this point is trying to address as way more serious issue in the community we need to address if it exists rather than something that should be at the side notes of the resolution about if we are going to give longer life to our stable branches or not. Is there any actual examples of such behaviour this point is targeting at (and I\u0027m not trying to get anyone pointing fingers here, yes or no is sufficient for me)?","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"d2beacbe761957b238148b475bd9b8462c0fe685","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_de36be51","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_35261917","updated":"2018-03-15 15:14:57.000000000","message":"I have a good example of issue we might land dealing with so just for clarity I\u0027d like to see it in a form of \"should not block proposed new fixes for a branch\". I feel strongly that because we were blocking https://review.openstack.org/#/c/525994/ for something that could have been taken as such, it should not mean that we should merge it because the branch turns to Extended Maintenance and \"the reasoning does not apply anymore because of the TC resolution\".","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"abee77b281cbd55bdd84d813723706dca67a4833","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_dfd7bced","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_3f7cb81d","updated":"2018-03-14 16:23:44.000000000","message":"Also wanted to note that with:\n\n\u003e \"we\u0027ll take fixes on branch N-3 and N-1 but not N-2\". That\u0027s not a technical reason to not accept fixes on N-2, it\u0027s a social issue driven by the agenda of the vendor dominating that project.\n\nThat would invalidate the 2nd bullet about fixes needing to go in order, so if a project said they\u0027d support N-1 and N-3 but not N-2, then they\u0027ve essentially stopped supporting N-3 because the fixes must go N-1 -\u003e N-2 -\u003e N-3.\n\nAnyway, hopefully this isn\u0027t an issue we ever have to deal with, but it came up in earlier discussions and was added here for posterity if nothing else.","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":6088,"name":"Emmet Hikory","email":"persia@shipstone.jp","username":"persia"},"change_message_id":"08d1caff203461509619efb3d8b1fb9fdd0a2b8f","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_6d328b60","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_62da9a4b","updated":"2018-03-14 14:56:18.000000000","message":"I believe this clause is structured this way such that any reason to not land a change is required to be a technical reason, therefore making the technical committee the appropriate escalation body in the event of a dispute.  I would prefer not to speculate on potential negative behaviour patterns that might have existed in the past or could potentially exist in the future, as any resemblance to actual people or situations might inadvertently cause injury.\n\nIf necessary, a potential additional clause might be:\n\n\"This means that if there is a dispute regarding the suitability of patch inclusion that requires governance oversight, it should be escalated to the technical committee, as with any other dispute of a technical nature.\"\n\nIn practice, I think all of our teams function well enough that this can mostly be ignored: there are regularly minor social and technical disputes in our community that are resolved without governance oversight, and I think the same rules apply for any branches subject to extended maintenance, excepting that the TC should be the oversight body to ensure consistent interpretation of the extended maintenance rules, at least until it becomes part of our shared culture.","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"42828282a93b6031923ccb1344247898733746fa","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_2d26d3cf","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_6d328b60","updated":"2018-03-14 15:06:35.000000000","message":"I like Emmet\u0027s proposed additional clause.\n\nI still find the original sentence confusing, though.  It\u0027s weird to use \"merit\" in the context of blocking a change, and I think the last clause is about the proposed patch, not the branch.  Or I have completely misunderstood the point?","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"30b1a7c0d900889fb969a3d9c17ba8aa2a3a26f6","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_2d754afa","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_de36be51","updated":"2018-03-15 18:23:24.000000000","message":"That patch isn\u0027t being debated over technical merit, it\u0027s being debated about whether or not it\u0027s an appropriate fix for stable branches. It enables a feature, so could be considered on one hand a feature backport, but it\u0027s also being argued that people are already running with this (broken) without that change and since it\u0027s self-contained it might be low risk and acceptable as an exception (from my skimming of the comments in there). I don\u0027t think it\u0027s falling into the same bucket of issue as what this point is for - which is a project team refusing to take patches in a specific branch simply because they don\u0027t support that stable branch.","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"5c123b7e55c547965ea643978187944751869271","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  This means if a bug is to be fixed in Ocata, it must also be fixed first"},{"line_number":124,"context_line":"  in Pike, and Queens before Pike, Rocky before Queens, etc. Fixes cannot"},{"line_number":125,"context_line":"  skip branches lest people would upgrade and be regressed."},{"line_number":126,"context_line":"* Project teams should not block proposed fixes for a branch based on the"},{"line_number":127,"context_line":"  non-technical merit of the proposed branch."},{"line_number":128,"context_line":"* Following on the last point, projects teams will not pick and choose EM"},{"line_number":129,"context_line":"  branches. For example, a project shall not say that Ocata and Queens can"},{"line_number":130,"context_line":"  have extended maintenance but Pike will not."}],"source_content_type":"text/x-rst","patch_set":3,"id":"df7087c5_35261917","line":127,"range":{"start_line":126,"start_character":2,"end_line":127,"end_character":45},"in_reply_to":"df7087c5_dfd7bced","updated":"2018-03-14 17:20:26.000000000","message":"@Matt: thanks for the explanation.  It sounds like you actually are talking about the merit of the branch.  Maybe dropping \"proposed\" in front of \"branch\" will make it more clear.  In any case, it\u0027s a minor point.","commit_id":"4cd1fc03ec10aa73eceb01c60ee2c173e885abe6"}]}