)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"05025178efb23f4c7a80966d0700bbf3c5e95bbf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"89a72d7d_d642aad6","updated":"2023-08-30 20:11:59.000000000","message":"@kristi, you wanna abandon this since it\u0027s been replaced, to get it outta review queues?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d05ae052a35805fab92cf3b6a77aeb8b0de1e430","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"aa65ef66_049ac9fd","updated":"2023-07-10 20:27:22.000000000","message":"After reading and discussion, I am not able to understand that how this proposal solve any of the problem we are currently facing with EM branches. It is adding a new problem of dis-integrating the EM concept 1. from user usage perspective 2. as well as extra maintenance (testing) overhead for projects want to keep EM. I am upgrading my vote to RC-Vote to -1.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"356fbf15e65e3b3daf96f6b7b237fcc48ae08fe1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b324107e_6fc9afa2","updated":"2023-07-12 18:59:21.000000000","message":"Based on discussion during the TC meeting of 2023-07-11, I will update this proposal to:\n\n1) rename extended maintenance to something else, like unmaintained or unsupported\n2) mention development of branches being moved to a new prefix, instead of stable/train, either unmaintained/train or unsupported/train\n3) clarify that +2/+A for these branches is going to be a separate Gerrit group, example nova-unmaintained-maint. Which may or may not be same as core or stable groups.\n4) remove wording that says that the project team is responsible for this branch.\n5) Include a checklist, or mention of a checklist being somewhere, related to the process of transition from maintained to unmaintained. ex. rename, and delete the periodic jobs, etc.\n\nWhat we haven\u0027t quite reached a consensus on the TC yet on and discussion will continue is related to:\n\n1) Testing expectations for this branch\n2) How long can we keep branches for and what\u0027s the process for removing them.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"60e6bc4e1124acb74b9d32bf78434c960f672fdd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"fc116c8d_1383cb56","updated":"2023-07-09 00:43:14.000000000","message":"I am OK with this as written, but I\u0027ll note -- we could add a specific place for an individual in the community to commit to supporting a branch, when EM is opted-into. This extra step of commitment can help clarify who is responsible; and give a venue for people who are people willing to maintain these branches to step up and make that effort.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":15993,"name":"Amy Marrich","display_name":"Amy Marrich (spotz)","email":"amy@demarco.com","username":"amarrich"},"change_message_id":"53a2c4d7a2c6f901cb2b1a07cf243c0d439136e5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"75079a46_7e2d9756","updated":"2023-07-10 21:37:19.000000000","message":"I think there\u0027s some good conversation going on in this review that might still need addressing but I think the premise is a good start.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"63d251f34f615285eb99446affb1370e9c653762","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"88e97f81_e2d26e4e","updated":"2023-07-10 19:31:00.000000000","message":"I\u0027m going to -1 this now that it\u0027s clear that the intent is just to basically make anything that isn\u0027t EOL equivalent to the existing stable/ branches. Without being able to drop intermediaries, and without the continued/reinforced expectation that the project teams are not the maintainers of those, I don\u0027t see how this is anything other than a worsening of the current situation.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"71b2f7c6a79a2b37f41fe9f80339665d38236e14","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ac4fd7bd_d4b92d6a","updated":"2023-07-18 14:19:58.000000000","message":"Proposal has been updated and available at https://review.opendev.org/c/openstack/governance/+/888771","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d050d6526fd4ef3684210aeafaf8eb1537ca6aa0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"cab3498b_8ef2f855","updated":"2023-07-10 16:58:52.000000000","message":"TBH, I\u0027m still in favor of a more extensive consideration of moving EM branches to a separate namespace and/or just pushing them to github and letting them sit.\n\nBut, a couple questions inline about this proposal if we go forward with it.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"38328b5a0dc228af16d712b2b94ade4580253e38","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3cc25663_6c9d624c","updated":"2023-07-11 08:27:55.000000000","message":"There may be room for tweaking, but in my opinion this proposal does two things, both net positive:\n- It codifies the current status quo: there are no magical external contributors coming; the project teams have to work to keep things working if we want them to keep working.\n- It ensures that smaller projects which focus less on OpenStack governance \"paperwork\" will not create zombie, unmaintained EM branches.\n\nFor those reasons, I\u0027m going to vote RC+1. That doesn\u0027t mean this can\u0027t be better; but it means this resolution as it sits today is more in line with the reality we\u0027re dealing with than the existing policies around EM.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f273c27b6f2c6a140b0e413d5e63cb08f3f3b9b9","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1cdee90b_1cab44fc","updated":"2023-07-11 09:16:40.000000000","message":"im actully gong to finally cr -1 this as i think this a step in the wrong direction too. i agree with much of the sentimetn about reducing the burden on project teams and eoling branchs and reducing testing for EM. i do not agree that we should codify the missunderstanding of EM and significnatly enhance the testing/supprot level of branches in EM. I think its reasonable to require working CI but not the full set that was used on master and to review EM branch supprot on an ongoing basis( at least once a cycle).\n\nso there are many element i agree with and many i dont but over all i think this as written is not a step forward.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"47e51e6b_5477bb26","updated":"2023-07-10 16:47:34.000000000","message":"just adding my thought on this here even we should be discussing the problem and possible solution in meeting/ML first that is why i created the below etherpad to give good amount of discussion before jumping to any solution\n\n- https://etherpad.opendev.org/p/openstack-exteneded-maintenance\n\nI see two main problems in our EM process 1. communication 2. maintenance overahead to upstream team. and this does not seems to solve any of those. \n\nProblem this proposal has:\n\n* users need these EM and in this proposal any project can decide to remove their all EM. user are nowhere and EM concept does not make sense. we do not allow/keep EM open for them to maintain when they need backport.\n\n* integrated projects are splitted here and any project move their EM to EOL will create hard time to test other integrated/dependent project. \n\n* current issue came when cinder want to move all their EM to EOL so this proposal is just documenting the same for all other project can do the same.\n\n\nI will prefer EM concept to be gone instead of handling it this way which create more issue then what we are facing currently.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"4d6740482433087498627703813dfc1499994eca","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"818e677a_b354a492","updated":"2023-07-10 06:09:25.000000000","message":"this looks good, thanks for proposing this!","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"47cbc0485773d9300ba66a4d6e03a4437551c717","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6c935ac5_84d5b469","in_reply_to":"47e51e6b_5477bb26","updated":"2023-07-10 19:25:24.000000000","message":"- \"any project can decide to remove their all EM\". We can\u0027t force anyone to keep their EM branches. If the CI is not working, and security fixes can\u0027t be backported, that branch should EOL and should not be kept around just because another project depends on it.\n- \"any project move their EM to EOL will create hard time to test other integrated/dependent project\". Yes, unfortunately. \n\n- \"I will prefer EM concept to be gone instead of handling it this way which create more issue then what we are facing currently.\" The same way I don\u0027t want to force a team to maintain an EM branch that they don\u0027t have the resources to maintain, I feel really strongly that we shouldn\u0027t force a team to stop maintaining a branch that they can and want to maintain. Therefore I see real value in preserving this aspect of EM, and is one of the primary goals of this resolution as I wrote it.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"}],"resolutions/20230707-extended-maintenance-new-requirements.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ca1aed74298cc785ec67d6fa466520e004040c8d","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"ad922ac5_7c3981aa","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"updated":"2023-07-07 16:58:16.000000000","message":"i think this is an existing misconception\n\nbranches in extended maintenance were not originally ment to be maintained primary by the project teams.\n\nthey were meant ot be maintained by the downstream distors and other our side of the project core teams.\n\noften there was a very high overlap between both groups but there was never a contract or commitment implied or otherwise  that the core teams of a given project would continue to maintain branches in extended mantachne.\n\nthe em branches were meant to be maintained by the user of the branch with help form the core teams as the had time for.\n\nits good to codify and correct this expecation that EM was anythign more then a best effrot attempt to maintian the branches before and more clearly defien it goign forward.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c1d93abc2296912b96059ca9a1b5eedf28be0bc5","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e04b879a_060dfad6","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"09bbb3e9_72c3c541","updated":"2023-07-14 02:17:35.000000000","message":"i would not percive RC-1 as “i’ll never let this pass” that not even what a CR-2 means.\n\ni would precive RC-1 as an indication that dan belived in its current form it should not be merged because there are substaial open issues and concenus has not been reached. Not a veto\n\nThe whole point of a rolecall vote is to allow TC memebr to indicate if they think the propaosl has reached concenus.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"4a75ffd0dac938e09334c44ebff0b5d2f1b87ed0","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"09bbb3e9_72c3c541","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"25827821_8225049b","updated":"2023-07-11 15:32:41.000000000","message":"Dan, I\u0027m absolutely not saying that. RC-1 sends a \"I\u0027ll never let this pass\" signal due to irreconcilable differences that can\u0027t be ironed out by any code-review process. If that is your intention, by all means please RC-1 and thank you for your feedback.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"2da00e10e21aacdeecfc51e35fa23aea2383aa8b","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"913a1d87_375d4375","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"2d5085f2_3f179d05","updated":"2023-07-11 09:29:10.000000000","message":"Frankly, we are extremely bad with user communication. We publish a large number of docs and websites, but they are often hard to find an understand. \n\nI\u0027m not sure we have the capability to sufficiently quash the expectation that if a branch exists, it\u0027s secure and usable.\n\nIn reality though, I think the cause here is not the documentation of expectations, or the project teams going above and beyond to support branches heroically -- our current situation is caused by two intersecting factors:\n- Our CI is sufficiently complex that it\u0027s extremely difficult for someone unfamiliar with *our CI specifically* to troubleshoot it. The most difficult OpenStack issues I\u0027ve ever had to troubleshoot were in our CI cloud; not in the highly scaled ones I\u0027ve run in the past.\n- The idea that someone external to the project teams would contribute enough to make these branches open just didn\u0027t pan out. Can someone give me a recent example of an EM branch that\u0027s maintained primarily by atypical contributors? I don\u0027t believe one exists.\n\nSo the problem is that reality is not aligning to our documentation. This change aligns our documentation with reality. Just because we write down that other people should be responsible doesn\u0027t mean those other people exist, and we\u0027re better off admitting that up front than continuing to support policies that are not based on reality.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f273c27b6f2c6a140b0e413d5e63cb08f3f3b9b9","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"a5abdc2f_975e53c3","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"2d5085f2_3f179d05","updated":"2023-07-11 09:16:40.000000000","message":"sure but we need to document the disconnect from what we aggree to do and the persception/expecation externally as that is the root cause of this issue.\n\nwe need to state clearly that operator/users did not understand what teams we commiting to with EM (Best Effort supprot with the expecation of reviewing backports but not active matainance). We need to be very clear going forward if we are changing that commit exactly how it is being changed.\n\nThe startign point is operators/users did not understand what extended maintaince was and assumed it was effectivly the same as full stable mantances which it never was. Project teams often exceed what they were requried to do and did not EOL branchs early enough and have not leverged there right to reduce testing on EM branches if the testing was not maintianed by contibutors.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"38320e33088809c27df87e5c2ee506b35fdf8c3f","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"eee64e1c_edf78012","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"5eaada3c_06fa2639","updated":"2023-07-10 18:22:40.000000000","message":"one good reason we discussed in forum sessions is that all those stable EM branch are under OpenStack/ namespace and under project team so the project team feel uncomfortable to keep them open and broken and endup maintaining it even there is no help from operator/user. Same I faced myself ith my QA hats on.\n\nThis is why we failed to communicate the real expectation. \"hey, this is a plant in MY YARD but you have to come water it to keep it alive\"  is hard to communicate instead we end up and everyone thinking \"hey, this is a plant in MY YARD so my responsibility to keep it alive\"","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"054c4cc14ff4bc8e7c72a4dcb42ad35ec8ca7077","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"5eaada3c_06fa2639","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"6381acf2_21d8ab66","updated":"2023-07-10 18:03:14.000000000","message":"they may expect it but we did not agree to it before and that expecation is one thing we need to correct.\n\neither we need to maintain the em barnches as if they were stable branches or we need to make it clear that the intent of EM branches is a best effort maintanch as orignially intended. i.e EM branches are maintained by the users of the EM branch.\n\n\nhttps://github.com/openstack/governance/blob/9a127069d468ea3508fc325f559af3170cb572f7/resolutions/20180301-stable-branch-eol.rst#L90 delegates the defintion fo Extended Maintaince to the stabel branch guide \n\nhttps://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases\nand the first paragrph is quite clear.\n\n\"\"\"\nOnce a branch reaches Extended Maintenance project teams will cease producing releases and OpenStack Vulnerability Management will be reasonable efforts only. There is no statement about the level of testing and upgrades from Extended Maintenance are not supported within the Community. There should not be an expectation on the upstream community team to keep maintaining the Extended Maintenance stable branches upstream testing. We will keep them open as long as possible so that any operator or user will be able to backport required fixes. Without regular comprehensive maintenance, it is quite possible that someone proposing a backport to an EM branch will find that tests have broken since the last successful merge. This means that tests (or test configuration) might need to be fixed, reduced, or reconfigured before the backport itself can be evaluated and merged. The onus for that falls on the backporter or the group of people looking after a specific release.\n\"\"\"\n\nparapahasing we sate:\n - no new release\n - VMT is best effort only \n - no statemnet on level of testing/upgrade supprot\n - There should not be an expectation on the upstream community team to keep maintaining the Extended Maintenance stable branches upstream testing.\n - EM branches are ketp open to allow operator and users to backport fixes.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"6381acf2_21d8ab66","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"82ba54e8_f1c22993","updated":"2023-07-10 16:47:34.000000000","message":"This is not true. we have got some feedback in vancouver summit discussion that operator does expect upstream team to keep EM up to dated. it is just us kept maintaining it for the reason I wrote in etherpad\n- https://etherpad.opendev.org/p/openstack-exteneded-maintenance#L33","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"031ecda490a7932118f5158acaa253bdbf36705d","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"a98cde1b_d14d2bfc","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"913a1d87_375d4375","updated":"2023-07-11 13:28:58.000000000","message":"The reason we started down this path is because the project teams are not able to handle the status quo. Codifying the status quo is not an improvement, IMHO. I like the move to default-to-EOL but in the end, if the project teams are the ones maintaining it (now formally on the hook to do so) I doubt that it will be any different than deciding when to opt-in to EOLing a branch currently.\n\nI\u0027ll again reiterate that if we merely move any would-be-EM branch to a separate tree (basically, default-to-legacy), where it can live forever maintained or not (a la archive.ubuntu.org) then tooling can continue working (with alternate URLs), people can continue submitting patches if they want, etc. Default the core team to a \"legacy-maint\" group, which has a low barrier to entry. If nobody shows up to push patches there, then so be it. We\u0027d have clear delineation of what is receiving full support from the project teams and what is not, which would address the concerns we have today about people not realizing that branches that look just as supported as stable/zed are *not* receiving updates. Projects like Cinder and Nova would not need to delete branches to achieve that signaling, which would allow devstack to continue to work for other projects on that release, which would be *better* than what we have today where a single key project going away sinks the whole ship.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"dd78824995de000dc39e58aef571b3dd64c23d95","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e3259058_d0419f58","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"925401ad_ee5a208c","updated":"2023-07-11 14:58:20.000000000","message":"\u003e The reason we started down this path is because the project teams are not able to handle the status quo. Codifying the status quo is not an improvement, IMHO. I like the move to default-to-EOL but in the end, if the project teams are the ones maintaining it (now formally on the hook to do so) I doubt that it will be any different than deciding when to opt-in to EOLing a branch currently.\n\u003e I\u0027ll again reiterate that if we merely move any would-be-EM branch to a separate tree (basically, default-to-legacy), where it can live forever maintained or not (a la archive.ubuntu.org) then tooling can continue working (with alternate URLs), people can continue submitting patches if they want, etc. Default the core team to a \"legacy-maint\" group, which has a low barrier to entry. If nobody shows up to push patches there, then so be it. We\u0027d have clear delineation of what is receiving full support from the project teams and what is not, which would address the concerns we have today about people not realizing that branches that look just as supported as stable/zed are not receiving updates. Projects like Cinder and Nova would not need to delete branches to achieve that signaling, which would allow devstack to continue to work for other projects on that release, which would be better than what we have today where a single key project going away sinks the whole ship.\n\nAll about this resolution can be revised to clearly define a different why (fixing the misconception about maintenance), where (external namespace on Gerrit), who (separate group in Gerrit, no responsibility on project team) and those alone should not be ground for a RC-1 as we can work on these implementation details, including renaming this resolution.\n\nWhat I am against though, is keeping branches indefinitely open somewhere (including against a project team\u0027s wishes), even if it\u0027s an external namespace, when no development is happening in them and I invite you to please write another proposal that defines that process, so that we can hash out those details and get some feedback from the community regarding that.\n\nWhile I will be a RC-1 on it, I\u0027m open to dropping that if enough of the community signal a strong desire to keep branches open.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"9aecfbb3dda70260f4527b6840db202067355142","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"925401ad_ee5a208c","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"a98cde1b_d14d2bfc","updated":"2023-07-11 14:41:44.000000000","message":"\u003e There is an expectation from users and operators that these branches are in a state of maintenance and receiving the above.\n\nAs Sean also commented and referenced from the resolution: this is a misconception. It is \"best effort\", meaning, if backports are arriving AND stable cores review them, then it might be usable for others (regardless of that gets merged or not).","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"4d6740482433087498627703813dfc1499994eca","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"d2493ec9_d6b0cb3b","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"ad922ac5_7c3981aa","updated":"2023-07-10 06:09:25.000000000","message":"This is true about the initial intent but with my recent experience, there is an expectation from operators that the project team is responsible to backport, merge, fix CI etc for those branches.\nIt could be due to the nature of our current stable core team which mostly includes project cores (eg: there is a high overlap between cinder core and cinder stable core). Also if gate breaks in EM branches, the project team has the most knowledge around it and feels the need to provide a quick resolution since no one else is going to.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"73f7e005b9642a582074a156c3f6483d340751af","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"82ba54e8_f1c22993","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"d2493ec9_d6b0cb3b","updated":"2023-07-10 09:49:46.000000000","message":"I agree with Sean in this point. The EM is a best effort period (until the EOL). If the team doesn\u0027t have resources to make the needed backports or fix the CI, it could be decided to abandon this branch and move it to EOL.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"48463d9f720480300497f79f25c0f5bbf2d730ff","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b13123e1_98916709","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"e04b879a_060dfad6","updated":"2023-07-17 09:41:16.000000000","message":"I like Dan\u0027s idea of moving those branches somewhere else and maybe even changing it\u0027s name from EM to something else, like e.g. \"legacy\" branches.\nI think that this users\u0027 misunderstanding of the whole concept can be partially related to the unfortunate IMHO name \"Extended MAINTENANCE\" which may suggest that this is still maintained branch. And if it\u0027s maintained and in the same repo as all stable branches (which are really maintained) there may be (mis)understanding that those EM branches are also maintained by the same core team.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6131f99ba23236e435261221a881259e860e950a","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"25827821_8225049b","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"e3259058_d0419f58","updated":"2023-07-11 15:18:26.000000000","message":"Kristi, are you trying to say I should not be RC-1\u0027ing this patch because I\u0027m not happy with it landing as it is now? It seems like you\u0027ve preemptively RC-1\u0027d something that hasn\u0027t even been written yet, so I\u0027m definitely confused on what rules of order you\u0027re referencing. Please do point me at those if I\u0027m missing them.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":15993,"name":"Amy Marrich","display_name":"Amy Marrich (spotz)","email":"amy@demarco.com","username":"amarrich"},"change_message_id":"53a2c4d7a2c6f901cb2b1a07cf243c0d439136e5","unresolved":true,"context_lines":[{"line_number":21,"context_line":"- The reality of most current EM branches is that they are not always"},{"line_number":22,"context_line":"  maintained and do not always receive security or bug fixes, or are in"},{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."}],"source_content_type":"text/x-rst","patch_set":3,"id":"2d5085f2_3f179d05","line":25,"range":{"start_line":24,"start_character":0,"end_line":25,"end_character":51},"in_reply_to":"eee64e1c_edf78012","updated":"2023-07-10 21:37:19.000000000","message":"Keep in minf Kristi is trying to provide a backstory as it\u0027s perceived here. Whether it\u0027s the original intent or not it\u0027s the feedback that\u0027s been provided.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ca1aed74298cc785ec67d6fa466520e004040c8d","unresolved":true,"context_lines":[{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Additionally, due to:"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"2683e6a3_589aa066","line":28,"range":{"start_line":26,"start_character":2,"end_line":28,"end_character":14},"updated":"2023-07-07 16:58:16.000000000","message":"ya for the most part it htink that is true that instead of the project teams only maintain the 3 branch that are not in EM we ended up maintaining the EM branches too.\n\nwith my downstream hat on the was an invensted interest in also maintianing the EM branches that our downstream product are based on but there is both a cost and a benefit of that.\n\nthat maintaince is or was often best done in the open so that all coudl benifit form the backports and fixes but it sometime ment backprot n release upstream and y release downstream.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Additionally, due to:"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"85275624_d7ccb97f","line":28,"range":{"start_line":26,"start_character":2,"end_line":28,"end_character":14},"in_reply_to":"2683e6a3_589aa066","updated":"2023-07-10 16:47:34.000000000","message":"true, same story for QA team, we explicitly called out QA not responsible for maintaining the EM testing but we end up doing that. It takes lot of time in fix and test the old compatible tempest version for any branch move to EM state.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"9aecfbb3dda70260f4527b6840db202067355142","unresolved":true,"context_lines":[{"line_number":23,"context_line":"  a state of not being able to merge those fixes if proposed."},{"line_number":24,"context_line":"- There is an expectation from users and operators that these branches are"},{"line_number":25,"context_line":"  in a state of maintenance and receiving the above."},{"line_number":26,"context_line":"- These branches are still maintained by the project teams themselves and are"},{"line_number":27,"context_line":"  taking attention and resources away from maintained branches and new"},{"line_number":28,"context_line":"  development."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Additionally, due to:"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"45f7bd59_ea7f415e","line":28,"range":{"start_line":26,"start_character":2,"end_line":28,"end_character":14},"in_reply_to":"85275624_d7ccb97f","updated":"2023-07-11 14:41:44.000000000","message":"anyone can backport / propose stable fixes, but unfortunately AND fortunately, to get them merged we still need someone with stable core rights.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"48463d9f720480300497f79f25c0f5bbf2d730ff","unresolved":true,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"This resolution identifies that"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"- There is value in allowing a project team to choose to maintain a release"},{"line_number":50,"context_line":"  for longer."},{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e338acad_5357baed","line":49,"range":{"start_line":49,"start_character":29,"end_line":49,"end_character":43},"updated":"2023-07-17 09:41:16.000000000","message":"project team or some interested 3rd party companies which are using this branch?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":49,"context_line":"- There is value in allowing a project team to choose to maintain a release"},{"line_number":50,"context_line":"  for longer."},{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"}],"source_content_type":"text/x-rst","patch_set":3,"id":"83f374e9_5f3fb93a","line":52,"range":{"start_line":52,"start_character":10,"end_line":52,"end_character":73},"updated":"2023-07-10 16:47:34.000000000","message":"we still need external team to help in maintaining it. we should not exclude those and make project team only to maintain it.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"38320e33088809c27df87e5c2ee506b35fdf8c3f","unresolved":true,"context_lines":[{"line_number":49,"context_line":"- There is value in allowing a project team to choose to maintain a release"},{"line_number":50,"context_line":"  for longer."},{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ee1ef3c_8fe8b62e","line":52,"range":{"start_line":52,"start_character":10,"end_line":52,"end_character":73},"in_reply_to":"4d1872dd_cb80b149","updated":"2023-07-10 18:22:40.000000000","message":"that is why i am saying this is changing  process from \"EM are not responsibility of project team\" -\u003e \"EM branches (opt-in) are mandatory responsibility of project team\" and I am not sure how it solve the current problem of maintenance ?\n\nFor me, this way project team will just kill all their EM because they cannot maintain it. and not sure how that is different than just killing the EM concept itself.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"054c4cc14ff4bc8e7c72a4dcb42ad35ec8ca7077","unresolved":true,"context_lines":[{"line_number":49,"context_line":"- There is value in allowing a project team to choose to maintain a release"},{"line_number":50,"context_line":"  for longer."},{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4d1872dd_cb80b149","line":52,"range":{"start_line":52,"start_character":10,"end_line":52,"end_character":73},"in_reply_to":"83f374e9_5f3fb93a","updated":"2023-07-10 18:03:14.000000000","message":"agreed project teams dont have the capasity to maintain all EM branchs as if they were non EM stable branches.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"37a14b3c49ab554fe07bd89f7d7458ecb2467935","unresolved":true,"context_lines":[{"line_number":49,"context_line":"- There is value in allowing a project team to choose to maintain a release"},{"line_number":50,"context_line":"  for longer."},{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dd09aded_2070fc69","line":52,"range":{"start_line":52,"start_character":10,"end_line":52,"end_character":73},"in_reply_to":"9ee1ef3c_8fe8b62e","updated":"2023-07-10 19:56:21.000000000","message":"well with my downstream hat on I prefer backporting upstream only as there is better pre merge coverage and overall less paperwork if i just fix an issue upstream and back port it upstream.\n\nit also means the fix im backporting is benifiting more people.\n\nSo while i am personally ok with EOLing old EM branches espically if they have broken ci, i would also be happy to see wallaby maintained as EM for then next 12 months.\n\neffectively i dont think peopel shoudl run a openstack release for more then 24-36 months.\n\nreally i would not personally keep any given release in production for more then 24 months before upgrading but i understand that most companies need a litte buffer on either end to do the upgade. \n\nswapping back to my upstream stable hat currently we maintain a barnch for 18 months in the stable branches before it goes EM. i dont really think the EM phase should extend beyond an addtional 6-18 months(depending on interest and mataince/ci).\n\nThat would allow operator to stay up to one slrup release behind the current latest slrup release with some level of upstream maintiance. that said i think the operators that truly understand openstack also understand the the benefit of upgrading promptly  on every release or at least every slrup release.\nso large deployments like cern ovn and vexhost are not going to be affected in either case.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"48463d9f720480300497f79f25c0f5bbf2d730ff","unresolved":true,"context_lines":[{"line_number":49,"context_line":"- There is value in allowing a project team to choose to maintain a release"},{"line_number":50,"context_line":"  for longer."},{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bdab4ea7_d79f68f7","line":52,"range":{"start_line":52,"start_character":10,"end_line":52,"end_character":73},"in_reply_to":"dd09aded_2070fc69","updated":"2023-07-17 09:41:16.000000000","message":"\u003e effectively i dont think peopel shoudl run a openstack release for more then 24-36 months.\n\u003e \n\u003e really i would not personally keep any given release in production for more then 24 months before upgrading but i understand that most companies need a litte buffer on either end to do the upgade. \n\u003e \n\u003e swapping back to my upstream stable hat currently we maintain a barnch for 18 months in the stable branches before it goes EM. i dont really think the EM phase should extend beyond an addtional 6-18 months(depending on interest and mataince/ci).\n\u003e \n\nMaybe we should then have some \"hard\" limits for it, like after 18 or 24 months after EM started, branch is going to be EOL.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ca1aed74298cc785ec67d6fa466520e004040c8d","unresolved":true,"context_lines":[{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"},{"line_number":56,"context_line":"  of quality for those branches that matches the expectations of users,"},{"line_number":57,"context_line":"  operators, and developers themselves."}],"source_content_type":"text/x-rst","patch_set":3,"id":"61e1a868_58c7a3e5","line":54,"updated":"2023-07-07 16:58:16.000000000","message":"this is sad but pretty true.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":17685,"name":"Elod Illes","email":"elod.illes@est.tech","username":"elod.illes"},"change_message_id":"9aecfbb3dda70260f4527b6840db202067355142","unresolved":true,"context_lines":[{"line_number":51,"context_line":"- It is  the project teams themselves that perform the maintenance in these"},{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"},{"line_number":56,"context_line":"  of quality for those branches that matches the expectations of users,"},{"line_number":57,"context_line":"  operators, and developers themselves."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fe226334_9a2b0f61","line":54,"in_reply_to":"61e1a868_58c7a3e5","updated":"2023-07-11 14:41:44.000000000","message":"indeed, this is 99% the sad truth. on the other hand, time to time i see patches coming from people not part of a project team (\"external actors\"?). though the amount of such patches are still insignificant, i agree. because of this, yes, we can consider this as a failed attempt.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"},{"line_number":56,"context_line":"  of quality for those branches that matches the expectations of users,"},{"line_number":57,"context_line":"  operators, and developers themselves."},{"line_number":58,"context_line":"- The process of opting-in needs to be manual rather than automatic."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"This resolution therefore attempts to preserve the ability for teams to choose"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ac58bb76_52c74fdf","line":57,"range":{"start_line":55,"start_character":0,"end_line":57,"end_character":39},"updated":"2023-07-10 16:47:34.000000000","message":"+1, that is where testing expectation was going wrong. we kept doing complete testing there even expectation was minimum testing.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"054c4cc14ff4bc8e7c72a4dcb42ad35ec8ca7077","unresolved":true,"context_lines":[{"line_number":52,"context_line":"  branches rather than external actors (operators, users, vendors, etc.) and"},{"line_number":53,"context_line":"  that the ideal of these branches encouraging collaboration from external"},{"line_number":54,"context_line":"  actors didn\u0027t manifest."},{"line_number":55,"context_line":"- There is a need for clear requirements and guidelines to maintain a standard"},{"line_number":56,"context_line":"  of quality for those branches that matches the expectations of users,"},{"line_number":57,"context_line":"  operators, and developers themselves."},{"line_number":58,"context_line":"- The process of opting-in needs to be manual rather than automatic."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"This resolution therefore attempts to preserve the ability for teams to choose"}],"source_content_type":"text/x-rst","patch_set":3,"id":"825aea9d_fc5d23f9","line":57,"range":{"start_line":55,"start_character":0,"end_line":57,"end_character":39},"in_reply_to":"ac58bb76_52c74fdf","updated":"2023-07-10 18:03:14.000000000","message":"ya we were allowed to drop testign but did not but this is nto the only thing that went wrong the other is that operator assuemd that Extended magaintacne was anythign mroe then best effort on the project teams part. reducing testing alone will not enable us to keep EM branches with our currnt contirbutor capasity.\n\nwe need more reviews and contirbutions form users/operators that are using them.\nif we dont have maintainers we shoudl EOL them instead.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d050d6526fd4ef3684210aeafaf8eb1537ca6aa0","unresolved":true,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The first branch this policy will apply to is stable/yoga. A sister resolution"},{"line_number":66,"context_line":"will be proposed concerning what to do with the current branches under"},{"line_number":67,"context_line":"extended maintenance."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fffb94a8_a7c6aa0c","line":67,"updated":"2023-07-10 16:58:52.000000000","message":"Okay, so am I summarizing this correctly as \"instead of EM lasting forever until a project actively chooses to EOL a branch, we will EOL candidate branches unless the project continues to \u0027renew\u0027 the EM-ness of that branch\" ?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"58d2afcf45da334bdf33b676008f28d761faf151","unresolved":true,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The first branch this policy will apply to is stable/yoga. A sister resolution"},{"line_number":66,"context_line":"will be proposed concerning what to do with the current branches under"},{"line_number":67,"context_line":"extended maintenance."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"15b239a4_7299d2ab","line":67,"in_reply_to":"fffb94a8_a7c6aa0c","updated":"2023-07-10 19:12:14.000000000","message":"Yes, the goal of this resolution is to make EOL-ing branches the default action most projects will take. But if an individual team still wants to really do extended maintenance, or has found external and willing maintainers they can put the work and we will not stop them.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"73f7e005b9642a582074a156c3f6483d340751af","unresolved":true,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."}],"source_content_type":"text/x-rst","patch_set":3,"id":"83f0db39_aa860c36","line":71,"updated":"2023-07-10 09:49:46.000000000","message":"I have one question related to the backporting process: it is mandatory to enforce the backporting process (for any kind of patch that requires to be backported) up to the oldest EM branch?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."}],"source_content_type":"text/x-rst","patch_set":3,"id":"6eeb8aa3_220c1790","line":71,"in_reply_to":"0a9541b9_43e69ed7","updated":"2023-07-10 16:47:34.000000000","message":"this has been same as it is. there is no expectation or requirement to backport to oldest EM. it is upto where we think we can backport or users want us to backport. One good example is nova/cinder volume attach CVE which we tried best to backport till stable/wallaby","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"d7223dd6646273d621fc385438e68fa3bd4fc92e","unresolved":true,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."}],"source_content_type":"text/x-rst","patch_set":3,"id":"880f8ceb_d8916a6c","line":71,"in_reply_to":"83f0db39_aa860c36","updated":"2023-07-10 14:30:26.000000000","message":"As currently written, if it\u0027s a security fix, there is probably an expectation for it to be backported, but not a requirement.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"0da89d990b58a29502fae7345a565e7de7258b6d","unresolved":true,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."}],"source_content_type":"text/x-rst","patch_set":3,"id":"0a9541b9_43e69ed7","line":71,"in_reply_to":"880f8ceb_d8916a6c","updated":"2023-07-10 14:36:30.000000000","message":"Though, to further elaborate the thought. While there may not be a requirement, the inability to fulfill the expectation of backporting a security fix is a good indicator of when it\u0027s time to transition a branch to EOL. I wouldn\u0027t be opposed to including it in the requirements.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ca1aed74298cc785ec67d6fa466520e004040c8d","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"71eb5c8e_f96b1725","line":76,"updated":"2023-07-07 16:58:16.000000000","message":"+1","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f273c27b6f2c6a140b0e413d5e63cb08f3f3b9b9","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"f4f3eb05_f685ddc6","line":76,"in_reply_to":"10b57628_b03a9aae","updated":"2023-07-11 09:16:40.000000000","message":"FFU specicifally was alway an insaller supported feature not a porject supproted one.  Nova neutron ectra never actully supported FFU jsut back to back rolling upgrade. That said we did not reject bug fixes for it as they are generally real bugs but we have only ever offically supprote n to n+1 upgrades before the new SLURP lifecycle.\n\ni should also point out that the current EM process say upgrades form EM branches are explictly not supported in teh comuntity.\nso once a banch hits EM there was no commitment or expectation that upgrades woudl be maintained from EM branches.\n\nthe second sentence of \nhttps://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance \n\n\"There is no statement about the level of testing and upgrades from Extended Maintenance are not supported within the Community.\"\n\nso to be clear if we are expecting to supprot upgreades as a guarentee espeically FFU or skip level that would be a signifcantion increase in the level of support implied by EM. And a signifcantly increased burden on project teams if we are reqiured to support this. to be clear we do test with grenede on EM barnaches today and we do fix minior issues with iti but if its complex then we look to EOL the branch. we dont however claim that upgrades work in any specific installer and if they broke in tripleo or OSA or Kolla we would not nessisarly EOL the branch if it still work in devstack. note devstack/greande is only special in this case becuase its what we use for testing. we could have drop the upgrade testing entirly but didnt if it was not broken.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"48463d9f720480300497f79f25c0f5bbf2d730ff","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"caf3167d_81b22aee","line":76,"in_reply_to":"4fa708c0_17a3cc7b","updated":"2023-07-17 09:41:16.000000000","message":"I\u0027m not sure I agree with this potential problem with upgrading from e.g. T-\u003eU where T is still EM and U would be EOL already and hitting some regression in U there. If someone is upgrading to the already EOL branch then IMO he is asking for the troubles and may expect different issues to happen there.\nOf course there are FFU upgrades, but those should be provided by the downstream teams and project\u0027s core team shouldn\u0027t be taking care of those maybe.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"a0dfdbdfd2376def17adf8a12893ac3ab9566c54","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"10b57628_b03a9aae","line":76,"in_reply_to":"57953a51_e8d3548a","updated":"2023-07-10 19:50:36.000000000","message":"There might be a bug breaking FFU that doesn\u0027t allow you to go from T-\u003eX because it\u0027s not fixed in one of those intermediary releases.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d050d6526fd4ef3684210aeafaf8eb1537ca6aa0","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"c076c76a_89440b11","line":76,"in_reply_to":"71eb5c8e_f96b1725","updated":"2023-07-10 16:58:52.000000000","message":"Does this mean we can\u0027t keep T on EM but EOL U? I\u0027m not sure I agree that\u0027s a necessary or beneficial requirement. If T is used by multiple downstreams but U is not, then I don\u0027t really see any reason why we couldn\u0027t EOL U and start skipping it when backporting things from master. If the point here is to reduce the burden it takes to keep an EM branch open, I would think reducing the steps that each patch has to go through would be beneficial.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"054c4cc14ff4bc8e7c72a4dcb42ad35ec8ca7077","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"c0d322d1_66c3585e","line":76,"in_reply_to":"c076c76a_89440b11","updated":"2023-07-10 18:03:14.000000000","message":"my +1 was more that if there is an intermdiary branch open i dont think it should be skipped.\n\nim also not sure i like the idea of EOLing intermediary branches early but im not entirly agaisnt it. if a new branch is not EOL i think we shoudl back port through that as normal as we should not have regressions on upgrades.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e29eb472c0a03e3eff66c6d598740bac6946fab3","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e654df19_a2ad741a","line":76,"in_reply_to":"c0d322d1_66c3585e","updated":"2023-07-10 18:23:49.000000000","message":"I definitely agree that if it\u0027s open, it shouldn\u0027t be skipped. However, I don\u0027t think I see a need to keep them open just to enable an older release. Like Canonical\u0027s LTS model, the intermediate releases lose support and then things go straight back to the previous LTS.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"58d2afcf45da334bdf33b676008f28d761faf151","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fc8c5d96_bb6d6b59","line":76,"in_reply_to":"e654df19_a2ad741a","updated":"2023-07-10 19:12:14.000000000","message":"During the forum session someone raised the following point with regards to EOL of intermediary branches:\n\nIf someone is on T, where T is still under EM, and upgrades to U, where U is EOL they may unknowingly encounter security regressions after upgrading T -\u003e U.\n\nThere is an expectation that every successive branch contains all of the preceding fixes which we would be breaking here as we\u0027re not detailing a LTS process.\n\nOnce we have a few SLURP releases approaching EM we can reconsider this policy with regards to SLURP -\u003e SLURP and dropping the intermediary.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"031ecda490a7932118f5158acaa253bdbf36705d","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"4fa708c0_17a3cc7b","line":76,"in_reply_to":"f4f3eb05_f685ddc6","updated":"2023-07-11 13:28:58.000000000","message":"Right, what Sean said.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"63d251f34f615285eb99446affb1370e9c653762","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."}],"source_content_type":"text/x-rst","patch_set":3,"id":"57953a51_e8d3548a","line":76,"in_reply_to":"fc8c5d96_bb6d6b59","updated":"2023-07-10 19:31:00.000000000","message":"Sure, but the same thing happens if you upgrade from an ubuntu LTS and don\u0027t go straight to the next LTS. If you\u0027re on a super old version, then I think your option is to FFU your way to the next supported release.\n\nIf we\u0027re going to keep the requirement that all intermediary releases after the oldest EM have to be maintained similarly, I\u0027ll definitely be pushing to EOL sooner than later.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"e15b6a1a_16f1f7e6","line":77,"range":{"start_line":77,"start_character":51,"end_line":77,"end_character":72},"updated":"2023-07-10 16:47:34.000000000","message":"and what are the expectation after opt-in? is project team mandatory to keep CI (unit, functional, integration) on EM in good condition same as other stable branches? including upgrade testing?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"2da00e10e21aacdeecfc51e35fa23aea2383aa8b","unresolved":true,"context_lines":[{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"c5a123c8_e69ffb8c","line":77,"range":{"start_line":77,"start_character":51,"end_line":77,"end_character":72},"in_reply_to":"e15b6a1a_16f1f7e6","updated":"2023-07-11 09:29:10.000000000","message":"I interpreted this, and would be fine with it being extended with this information, as -- if you want your governance change merged to opt-in to EM, you need to have a green CI on that branch -- whatever CI your project determines is needed.\n\nI don\u0027t see this as an item intended to require teams to operate significant CI but instead that they are active enough to ensure their CI is not a burden unto the other OpenStack teams.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"a50e66d0b116ac9e626d46defc6049c814492f91","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1b0bbdd7_31fd404c","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"updated":"2023-07-10 18:02:24.000000000","message":"One more question, with these requirement here project team is 0% responsible for these branches then what is difference between supported maintained branches and EM? why cannot we say any project can extend the life cycle of supported maintained branch (more than 18 months) and move to EOL directly.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e29eb472c0a03e3eff66c6d598740bac6946fab3","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1e6560fc_ae3c64d5","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"1b0bbdd7_31fd404c","updated":"2023-07-10 18:23:49.000000000","message":"I read this as the project/liaison is responsible for the opt-in, but not necessarily for the maintenance on the tree itself. Meaning, the project may say \"yeah, keep T open because those redhat guys are maintaining it\" or \"we\u0027re not opting into keeping T open anymore because the people supporting it have vanished.\"\n\nBasically I think (hope) that this is not *increasing* the support burden on the project, only adding a requirement that the project continue to \"renew\" the opt-in to EM.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"8bfd272eb05ac46cb824971bbb25c8e7869dd304","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7a40af6b_64c98337","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"1e6560fc_ae3c64d5","updated":"2023-07-10 18:43:11.000000000","message":"I just realized my typo of 0% responsible (I meant to say 100% responsible and my keyboard did not type first two digit :)).\n\nWhat I am reading is especially the line72 \"....all branches they want to keep supporting under extended maintenance....\" project has to maintain it 100%.  If it is like you mentioned than it is same as what we have currently? so let\u0027s not write that here to avoid confusion of this as a new requirement. or say explicitly as \"keep those branches *open* for people (who are interested) to maintain it\"","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"687797c8566f1ddbc6c8de5401aaa3c0c0a578c4","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"63535508_420eb300","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"31d54de9_a2b1cbe0","updated":"2023-07-10 20:11:50.000000000","message":"\u003e Would you as a Nova core developer, let Nova\u0027s EM branch go unmaintained with security fixes and a broken gate just because it\u0027s in a different namespace?\n\nI wouldn\u0027t (necessarily) be on the core team there, so.. yes? To me, putting it in a different namespace would be equivalent to anyone forking nova at any random time on github and not updating (or moving on) from the parent repo.\n\nAnd yes, I think when someone goes to the main official nova repo and drops down the branches box, they would not (and clearly do not) understand the difference between stable/train and stable/zed  in terms of how and how much is being done there. If they did, then we wouldn\u0027t need to EOL branches in the first place.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"f273c27b6f2c6a140b0e413d5e63cb08f3f3b9b9","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9520205a_10e237e9","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"4ab1b790_5675492b","updated":"2023-07-11 09:16:40.000000000","message":"right i dont think we should codify the missunderstading fo what EM ment\nand i do agree that with dan that defaulting to EOLing the branches would be a step forward.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"66ca45a03f80ea44b2ff0fa86522a8bdad9e8013","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4ab1b790_5675492b","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"4d0de070_834c8a2e","updated":"2023-07-10 21:03:51.000000000","message":"Right, this seems to me like a codification of the current misunderstanding, and as such, seems like a step in the wrong direction.\n\nHOWEVER, there is one new thing in this proposal that I _do_ support, which is \"default to EOL unless renewed as EM\" which I think is a good idea. I just think that we should *not* tie that to formally placing responsibility for EM maintenance on the project teams.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"a1737f049a61542aa30c42cb66edbccb60b5f19f","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"31d54de9_a2b1cbe0","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"5c9a44c8_319ca73e","updated":"2023-07-10 19:59:25.000000000","message":"The difference between supported and EM are that\n- Supported is done in an integrated manner. All OpenStack projects (that release as part of a cycle) participate, there\u0027s cross projects testing, security monitoring, point releases, etc.\n- New EM is a choice of an individual team. They choose the level of testing and maintain the branches open and CI working. Which are minimum expectations for receiving this types of backports.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d05ae052a35805fab92cf3b6a77aeb8b0de1e430","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f24c68d4_e29ebc6e","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"63535508_420eb300","updated":"2023-07-10 20:27:22.000000000","message":"I also do not see any difference between supported and EM branch after this. A simple question if project team is mandatory to maintian opt-in EM branch then why to move them to EM itself.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"13992d6667d4c6efce355011d0588215ce3457f5","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8ba9de07_43bd2818","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"63535508_420eb300","updated":"2023-07-10 20:26:59.000000000","message":"If it goes unmaintained like the situation above I described above because there are no external maintainers and none of the core members of Nova want to pick up the work, would you agree that it\u0027s time to move it to EOL?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"63391899827140d48b9380162aeed0cb0cef05e8","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7e7a4bba_a50d0866","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"7a40af6b_64c98337","updated":"2023-07-10 19:01:38.000000000","message":"Okay, I thought you *meant* 0% because my understanding of this is that only the new requirements (i.e. the opt-in each cycle) were being placed on the project/liaison and not the actual day-to-day maintenance. Let\u0027s get clarification from Kristi here and definitely tighten up the language so it\u0027s not ambiguous.\n\nIf this *is* proposing that the projects formally become responsible for the maintenance of all the EM branches (which is happening now, but not supposed to be) then I\u0027m definitely -1 on this, because as you say, that\u0027s the same as just doubling (or more) the number of supported branches AFAICT.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"58d2afcf45da334bdf33b676008f28d761faf151","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"eb2622ef_643ee172","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"7a40af6b_64c98337","updated":"2023-07-10 19:12:14.000000000","message":"Whether we like it or not, the project team *is* responsible for a branch under extended maintenance. They are the reviewers who will hit +2/+W and for most cases they will also be the ones fixing the gate and backporting fixes. Keeping the branch open and being hopeful that someone will pick up the work has not and will not work.\n\nI want people to EOL branches they can\u0027t meaningfully maintain instead of keeping them open. This is not creating more work than people are willing to do. In fact it\u0027s reducing work because if you don\u0027t have the resources or desire to do extended maintenance, the branch will just go away on its own rather than you having to take action.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"48463d9f720480300497f79f25c0f5bbf2d730ff","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f079e3ba_6b342f80","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"9520205a_10e237e9","updated":"2023-07-17 09:41:16.000000000","message":"For me the main 2 differences between maintained and EM branches will still the same as they are now:\n\n* no new releases published for those EM branches,\n* best effort CI with allowance to remove some broken scenario jobs if needed.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"d3a20fa4c62ba6923bb7f7fea884aa939dbfd6ac","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f6a6051b_2779ad40","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"9df5f445_0b40ac19","updated":"2023-07-10 20:40:39.000000000","message":"Gmann, if your disagreement is with the mention of project team being responsible, I can change the wording to clarify that the liaison could be external from the team.\n\nIf your disagreement is that we should strive to keep branches open somewhere even when unmaintained, then I have to respectfully disagree with your diagnosis of the problem.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"a0dfdbdfd2376def17adf8a12893ac3ab9566c54","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5c9a44c8_319ca73e","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"e71448c9_a66fe01b","updated":"2023-07-10 19:50:36.000000000","message":"I don\u0027t think we\u0027re providing any value by chasing those external maintainers, and I don\u0027t think they\u0027re ever going to show up even if we change things structurally, move to a separate namespace, or platform.\n\nWould you as a Nova core developer, let Nova\u0027s EM branch go unmaintained with security fixes and a broken gate just because it\u0027s in a different namespace?\n\nThe problem I\u0027m trying to solve is starting from the point of this kind of this kind of maintenance not working.\n\nSo there are 3 ways forward\n- Make it unmaintained and nobody is fixing it\n- Kill EM entirely and let no teams to EM\n- Allow EM for some teams.\n\nI went with the last and that\u0027s the problem I\u0027m trying to solve.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"63d251f34f615285eb99446affb1370e9c653762","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e71448c9_a66fe01b","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"eb2622ef_643ee172","updated":"2023-07-10 19:31:00.000000000","message":"\u003e Whether we like it or not, the project team *is* responsible for a branch under extended maintenance. They are the reviewers who will hit +2/+W and for most cases they will also be the ones fixing the gate and backporting fixes. Keeping the branch open and being hopeful that someone will pick up the work has not and will not work.\n\nI think this is wrong. Whether we like it or not, they *have been* doing the needful, which brings that not-as-written expectation, but I think there\u0027s a strong desire to change that by making enough of a structural change that it\u0027s clearer. When EM became a thing the (unrealized) goal was to allow for maintainers of those branches *other* than the project teams. This, to me, is another good example of why moving namespaces would be better. If we\u0027re going to keep them here, I do *not* think we should be moving to formal responsibility for those branches, but rather only requiring them to own the EOL-or-renew-EM decision. I\u0027ll put my -1 on here on the basis that it sounds like you\u0027re expecting the former.\n\nIf that\u0027s the case, can you explain the difference between supported and EM after this resolution?\n\n\u003e I want people to EOL branches they can\u0027t meaningfully maintain instead of keeping them open. This is not creating more work than people are willing to do. In fact it\u0027s reducing work because if you don\u0027t have the resources or desire to do extended maintenance, the branch will just go away on its own rather than you having to take action.\n\nI really don\u0027t understand how this would solve the problem then.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"a624d5680d0beb4ac68837272f87d7ad36df8925","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9df5f445_0b40ac19","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"f24c68d4_e29ebc6e","updated":"2023-07-10 20:29:47.000000000","message":"we are again misunderstanding the concept of EM here. it is not about when we want to move EM to EOL. it is about we as upstream team want to keep EM open for anyone come and help/backport the things they need. EM in current process fail to do that so we need to find a solution how we can keep them open for users need them instead of discussing when to EOL.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"3e2e481cf128f24216b8e1b178d9b9b90bcc2f54","unresolved":true,"context_lines":[{"line_number":69,"context_line":"New Requirements for Staying in Extended Maintenance"},{"line_number":70,"context_line":"----------------------------------------------------"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"- A project team needs to opt-in every cycle for all branches they want to"},{"line_number":73,"context_line":"  keep supporting under extended maintenance by M-3."},{"line_number":74,"context_line":"- The PTL or Stable branch liaison is the point of contact for this process."},{"line_number":75,"context_line":"- No branches may be skipped between the oldest intended extended maintenance"},{"line_number":76,"context_line":"  branch and the current supported releases."},{"line_number":77,"context_line":"- The CI for all branches must be in good standing at the time of opt-in."},{"line_number":78,"context_line":"- The PTL or stable branch liaison is the point of contact within the project"},{"line_number":79,"context_line":"  team and responsible for the above requirements."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Extended Maintenance and Dependencies"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4d0de070_834c8a2e","line":79,"range":{"start_line":72,"start_character":0,"end_line":79,"end_character":50},"in_reply_to":"f6a6051b_2779ad40","updated":"2023-07-10 20:51:22.000000000","message":"That is why I started the etherpad to first agree on the problems we are facing with EM and something we can discuss in meeting/call and after that discuss the solution - https://etherpad.opendev.org/p/openstack-exteneded-maintenance\n\nhere you are addressing that \n1. \u0027any project can keep EM\u0027.\n2. \u0027any project can remove any number of EM or all EM\u0027\n\nAnd I am saying (since starting when this proposal discussed IRC and here also) this is no different than what our current policy is\n- https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance\n\nIt clearly say project can keep EM open/maintain which means:\n1. \u0027any project can keep EM\u0027.\n\nand another line from current policy: \"After a project/branch becomes unmaintained or a team decides to explicitly end support for a branch, it will become End of Life.\" it means:\n2. \u0027any project can remove any number of EM or all EM\u0027,\n\nso I am not finding what new this proposal bring and more than that how it solve the problems we are facing for EM process which is what I wrote in etherpad","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"733b69a662fda0498d045fd20f04e4a7cf79e5d8","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1b8cc8e4_8e5f8285","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"updated":"2023-07-10 16:47:34.000000000","message":"I donot think we have that. do you have any example where we have done that? \n\nWe tried when cinder move pike to EOL much ahead of other projects\nThis is my main concern on this opt-in proposal by projects instead of coordinated and consistent moving to supported to EM to EOL.\n\nI am sure if we need to use the EOL tag then most of the integrated/dependent projects CI will be broken or hard to maintain which clearly means they need to move to EOL also.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"054c4cc14ff4bc8e7c72a4dcb42ad35ec8ca7077","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"737d9dd6_9e122bf6","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"1b8cc8e4_8e5f8285","updated":"2023-07-10 18:03:14.000000000","message":"you can set NOVA_REPO to a tag/branch/git-sha in devstack for local development and testing.\n\nfor zuul however we woudl just use override-checkout on the relevnet repo since devstack is not actully clonning anything zuul is. \n\nthis would work the same way as we pin tempest more or less.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d05ae052a35805fab92cf3b6a77aeb8b0de1e430","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bb2ad285_d5a07ba3","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"279297d6_17fb1145","updated":"2023-07-10 20:27:22.000000000","message":"yes, a separate core team with something in different place than upstream activities and responsibility. that is where we our communication problem of EM is started, upstream team having something in their place think of maintaining responsibility.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"fd24cdb809e0d94a349a0288a8ae9d0288609601","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"8a9749f2_f6b743cd","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"448a0c3d_aa001a95","updated":"2023-07-11 00:28:42.000000000","message":"Different namespace need more discussion and also more implementation detail like Dan mentioned about infra etc. Let keep that a separate possible solution and what pre-infra it need.\n\nEOL-by-default might not be needed if we can have different namespace right?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"38320e33088809c27df87e5c2ee506b35fdf8c3f","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"e8406066_3bd4444f","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"737d9dd6_9e122bf6","updated":"2023-07-10 18:22:40.000000000","message":"I know, but my main point here is this is more complex, and QA team does not have the bandwidth to do/support that in tooling (it looks like less work, but it is not). If the project team needs to do this, then this is extra work to maintain EM for them, making EM branch maintenance even worse than today. That is why I am strongly against where it break the integrity. python min version bump is good example and why we need to move deps/testing for all project together even on stable, master branch or EM branch. if we do not keep that it will be very very difficult to keep testing on EM and all integrated project need to move their EM also to EOL even they want to maintain them for long term \n\n-","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"0a226c45e7512d848eb6229603d6a5d7bf8c17a6","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"d51b7d67_34698584","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"82696470_4c0cf328","updated":"2023-07-10 22:24:36.000000000","message":"I\u0027m not opposed to rewriting parts of this resolution to say that EM development will happen in a separate namespace under a different Gerrit group for +2/+W.\n\nDan, Gmann, Would that make you reconsider your -2?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c1d93abc2296912b96059ca9a1b5eedf28be0bc5","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3ef73c2d_c06477bc","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"8a9749f2_f6b743cd","updated":"2023-07-14 02:17:35.000000000","message":"right if its in a diffent  namespace we dont nessarlly need to eol.\nbut what would would need to do is tag and close the branch in the main project repo and ensure ensure it is imported into the other repo from that tag.\n\nif we have the openstack-em/nova repo then we should keep the same barnch open in both openstack/nova and openstack-em/nova.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"63d251f34f615285eb99446affb1370e9c653762","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"b7eca688_ab4f229e","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"94f9ae51_9bd04ea2","updated":"2023-07-10 19:31:00.000000000","message":"When EM became a thing, the original plan was to have community members step up to be \"core\" on those old branches. Because they\u0027re the same repo as master development that hasn\u0027t really happened. Moving to another namespace would make that a lot more palatable for people I think.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"37a14b3c49ab554fe07bd89f7d7458ecb2467935","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"279297d6_17fb1145","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"94f9ae51_9bd04ea2","updated":"2023-07-10 19:56:21.000000000","message":"presumably it could have a seeprate core team. we can bootstrap with the project stale cores but it should really be open to the operators/vendors/users that care to maintian it.\n\nwe proably still want to avoid regression on upgrades but we would have a clear seperation fo the release that are supproted by the project teams and the ones that are not.\n\nim not nessiarly a fan of this but its no worse then what we have today so it might be worth a try.  we coudl reduce the coverage on the seperate namespace to a reasonable minimal set and make it clear that the level of testing and maintaince is reduced vs maintained stable branches.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"a0dfdbdfd2376def17adf8a12893ac3ab9566c54","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"47472497_1650846e","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"b7eca688_ab4f229e","updated":"2023-07-10 19:50:36.000000000","message":"I don\u0027t think the namespace will have as much of an impact as you think. Cinder is still Cinder whether it\u0027s in openstack/cinder or openstack-legacy/cinder.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":15993,"name":"Amy Marrich","display_name":"Amy Marrich (spotz)","email":"amy@demarco.com","username":"amarrich"},"change_message_id":"53a2c4d7a2c6f901cb2b1a07cf243c0d439136e5","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"82696470_4c0cf328","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"bb2ad285_d5a07ba3","updated":"2023-07-10 21:37:19.000000000","message":"I kind of like this proposed idea of another namespace with it\u0027s own set of cores. It potentially take the pressure off the current teams while also potentially allow more folks to get involved. The only issue would be if no one steps up but I think that would be addressed by the opt-in discussion","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"aa8c52a68baf637619e8929ec1fd1dd3f50aea60","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"448a0c3d_aa001a95","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"d51b7d67_34698584","updated":"2023-07-10 22:33:44.000000000","message":"I think we need to get sign-off from infra and have a larger discussion about the namespace thing before we can resolve to that solution. I originally suggested it and it was sort of NAKed \"because reasons\" but the longer we\u0027ve discussed this the more it seems like it will solve a lot of our problems.\n\nSo I mean, yes, obviously that will address my concern about this codifying the bad situation right now, but I also think we might want to consider breaking up the EOL-by-default behavior from the \"how we get the projects to stop owning the EM branches\" part.","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"6761dea626567c3c443e73655dc667faa9008ca8","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"94f9ae51_9bd04ea2","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"e00a40f4_55065422","updated":"2023-07-10 19:16:01.000000000","message":"If we move things to a different namespace, how will the code review process work?","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"448f0f18454458b1b213d152a12552c1ce201259","unresolved":true,"context_lines":[{"line_number":99,"context_line":"  above of maintenance and creating an environment where teams work more"},{"line_number":100,"context_line":"  closely together to fulfill their common objective."},{"line_number":101,"context_line":"- shift their testing infrastructure to use tags instead of branches for their"},{"line_number":102,"context_line":"  dependencies. This is already possible with the current tooling and will"},{"line_number":103,"context_line":"  pull code that reflects the last state of the extended maintenance for that"},{"line_number":104,"context_line":"  repository."},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"e00a40f4_55065422","line":102,"range":{"start_line":102,"start_character":16,"end_line":102,"end_character":66},"in_reply_to":"e8406066_3bd4444f","updated":"2023-07-10 18:29:31.000000000","message":"It\u0027s also worth noting that this will \"make it work\" but it also means that the target dependent project is immutable, so if something else changes there\u0027s not even an opportunity to do a depends-on with an example patch to fix it.\n\nThat said, I think this is just a risk/caveat to the whole thing, and as stated in the doc here, I don\u0027t think there\u0027s any way we can force/require cinder (for example) to keep support for a branch just because nova wants to. Now, if we moved things to a different namespace where branches could just remain open forever....","commit_id":"d8c77a129ecdf3d97d021d6e13911760e7db0825"}]}