opendevreview | Kristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance https://review.opendev.org/c/openstack/governance/+/888771 | 12:43 |
---|---|---|
rosmaita | knikolla: lmk what you think of this: https://etherpad.opendev.org/p/openstack-unmaintained-transition | 15:41 |
*** jgwentworth is now known as melwitt | 16:18 | |
opendevreview | Kristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance https://review.opendev.org/c/openstack/governance/+/888771 | 19:35 |
knikolla | rosmaita: I don't have a strong preference on how aggressively we get rid of the current branches. what you proposed seems reasonable to me. Perhaps since RHOSP 17 is based on Wallaby, we might want to keep that one too. | 19:39 |
rosmaita | i think whatever makes sense for the community | 19:41 |
knikolla | gmann: I removed the maximum, but I would like to see some kind of maximum to be honest. The 3 years (2 unmaintained branches) that I initially proposed aligned with the level of support that Ubuntu gives us (5 years of support - 2 years in between releases depending on timing). And since most of our infra running tests is Ubuntu it made sense to draw the line there to me. | 19:41 |
gmann | knikolla: thanks, checking | 19:56 |
gmann | knikolla: ok, I am fine with that. added one more comment about to plan for the releases before SLURP concept. for example current policy is for SLURP only and it does not tell us what to do for yoga, zed and when they can move to EOL | 20:16 |
knikolla | gmann: would you be okay with language saying at most 3 unmaintained branches (both for slurp and non slurp) regardless of opt-in? So before SLURP, we keep up to Victoria until Yoga becomes unmaintained and then we drop Victoria? After SLURP that translates to around 4 years after release. | 20:21 |
dansmith | personally I think we should stick to only one automatic freebie | 20:23 |
dansmith | and require opt-in for the first and later renewals | 20:23 |
gmann | knikolla: then after SLURP (2023.1) 3 will be too long | 20:23 |
knikolla | dansmith: ++, i meant the maximum with renewals being 3. | 20:24 |
dansmith | I'm not really sure we need a maximum necessarily, but I'm not super opinionated | 20:24 |
knikolla | but only 1 automatic. | 20:24 |
gmann | maybe we can just say opt-in is there but for SLURP it will be 1 automatic option and before SLURP things it will be 3 automatic opt-in | 20:24 |
dansmith | yeah I don't much care what we decide for the past pre-SLURP releases, as long as they can age out at some point | 20:25 |
gmann | so it will be 1 automatic opt-in after we get rid of those 6 month upgradable releases | 20:25 |
dansmith | I thought knikolla was intending to treat those separately anyway with the sibling resolutions | 20:25 |
knikolla | dansmith: ++, yeah. | 20:25 |
gmann | I think we need to define policy for those also as they are mainly in question for now and which is what Cinder proposal is | 20:26 |
gmann | SLURP resolution is all good | 20:26 |
dansmith | gmann: right, but there are other resolutions proposed for those, we can discuss there I think | 20:26 |
gmann | dansmith: where ? | 20:26 |
gmann | so this resoltuion is for future things not for current EM thing ? | 20:27 |
dansmith | like this: https://review.opendev.org/c/openstack/governance/+/887968/1/resolutions/20230707-apply-em-requirements.rst | 20:27 |
dansmith | not saying it has to be this way I'm just saying I think that's knikolla's intent | 20:27 |
gmann | that was based on the original first resolution. if we go with the current resolution then either 1. we need to propose another resolution for existing EM (before SLURP things) or 2. adjust that in current proposal so that it include pre-post SLURP both branches | 20:29 |
gmann | 'extended-maintenance-new-requirements' this one | 20:29 |
dansmith | right, I'm just saying I think that's knikolla's intent | 20:30 |
dansmith | it sounds like we're coalescing around this new one, so perhaps he can update the sibling now | 20:30 |
dansmith | (or fold it in) | 20:30 |
gmann | I am ok with two separate resolutions also but we need to discuss and finalize that 2nd proposal also as that is what community and cinder team is looking for (the current EM branches maintenance ) | 20:30 |
gmann | sure, am ok with that | 20:31 |
rosmaita | gmann: dansmith: what do you think of this? https://etherpad.opendev.org/p/openstack-unmaintained-transition | 20:31 |
knikolla | I can either revise. Just didn't want to hold up one or the other based on implementation details that are separate. | 20:31 |
dansmith | rosmaita: yeah I think I said I was good with it | 20:33 |
gmann | rosmaita: that is good for SLURP things. but for pre-SLURP only allowing only one unmaintained seems less to me as till zed all releases are 6 month upgradable | 20:33 |
dansmith | either we can fold that into this, or (what I assumed would happen is) knikolla can replace the sibling content with basically this | 20:33 |
dansmith | I guess one resolution to reference will probably be easier for most people, but I seemed to be the only one that was confused by knikolla's initial two-phase commit so I assumed others were in favor of that approach | 20:34 |
gmann | dansmith: knikolla: ok for me. so what will be proposal for those ? | 20:34 |
gmann | keeping them in unmaintained pahse for a cycle to give time for maintainers who need them to opt-in those manually ? | 20:35 |
knikolla | Since we seemed to have reached consensus I'm okay folding it in to reduce churn and merge conflicts. | 20:35 |
dansmith | knikolla: ack so that would probably reduce confusion at this point | 20:35 |
knikolla | Everyone ok with the latest 3 EM branches transitioning to Unmaintained and keeping a rolling window of 3 until we have SLURP? | 20:36 |
gmann | yeah, in case community does not read the other one. | 20:36 |
rosmaita | knikolla: you mean v/w/x or x/w/y ? | 20:37 |
gmann | knikolla: ok with me. | 20:37 |
gmann | v/w/x i think as per current EM | 20:37 |
knikolla | we don't have yoga yet, so V/W/X | 20:37 |
gmann | and then w/x/y once yoga move out of 'Maintained' phase | 20:37 |
gmann | yeah | 20:37 |
knikolla | once Yoga is out, projects will have the option to opt-in to keep it. | 20:37 |
rosmaita | ok, cinder has already proposed to eol them all, so i guess i don't care | 20:38 |
gmann | ++ | 20:38 |
gmann | this way we give them chance who need then to come forward and maintain | 20:38 |
gmann | *them | 20:38 |
knikolla | Opt-out is totally okay :) rosmaita | 20:38 |
rosmaita | sounds good ... there has been no response to my "last call" email: https://lists.openstack.org/pipermail/openstack-discuss/2023-July/034346.html | 20:40 |
rosmaita | do we have any remaining concerns about coordinated guidelines for EOL-ing branches across projects? | 20:42 |
knikolla | We're still basically saying you're on your own if a project you depend on isn't doing EM/Unmaintained. | 20:48 |
opendevreview | Kristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance https://review.opendev.org/c/openstack/governance/+/888771 | 20:53 |
opendevreview | Kristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance https://review.opendev.org/c/openstack/governance/+/888771 | 20:56 |
gmann | rosmaita: because we are giving away the EM branches so it will be up to EM maintainers to keep all depended or needed project EM branches. we do not stop them to do neither provide any guarantee of any maintenance. For example companyA needs cinder and nova both, but only maintains cinder then they can jump into nova branches maintenance also if nova branch EOL happening before cinder | 21:04 |
gmann | knikolla: 1 comment (for consistency reading of who will opt-in) otherwise this lgtm. | 21:08 |
opendevreview | Kristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance https://review.opendev.org/c/openstack/governance/+/888771 | 21:11 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!