Monday, 2023-07-24

opendevreviewKristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance  https://review.opendev.org/c/openstack/governance/+/88877112:43
rosmaitaknikolla: lmk what you think of this: https://etherpad.opendev.org/p/openstack-unmaintained-transition15:41
*** jgwentworth is now known as melwitt16:18
opendevreviewKristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance  https://review.opendev.org/c/openstack/governance/+/88877119:35
knikollarosmaita: 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
rosmaitai think whatever makes sense for the community19:41
knikollagmann: 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
gmannknikolla: thanks, checking19:56
gmannknikolla: 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 EOL20:16
knikollagmann: 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
dansmithpersonally I think we should stick to only one automatic freebie20:23
dansmithand require opt-in for the first and later renewals20:23
gmannknikolla: then after SLURP (2023.1) 3 will be too long20:23
knikolladansmith: ++, i meant the maximum with renewals being 3. 20:24
dansmithI'm not really sure we need a maximum necessarily, but I'm not super opinionated20:24
knikollabut only 1 automatic. 20:24
gmannmaybe 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-in20:24
dansmithyeah I don't much care what we decide for the past pre-SLURP releases, as long as they can age out at some point20:25
gmannso it will be 1 automatic opt-in after we get rid of those 6 month upgradable releases20:25
dansmithI thought knikolla was intending to treat those separately anyway with the sibling resolutions20:25
knikolladansmith: ++, yeah. 20:25
gmannI think we need to define policy for those also as they are mainly in question for now and which is what  Cinder proposal is20:26
gmannSLURP resolution is all good20:26
dansmithgmann: right, but there are other resolutions proposed for those, we can discuss there I think20:26
gmanndansmith: where ?20:26
gmannso this resoltuion is for future things not for current EM thing ?20:27
dansmithlike this: https://review.opendev.org/c/openstack/governance/+/887968/1/resolutions/20230707-apply-em-requirements.rst20:27
dansmithnot saying it has to be this way I'm just saying I think that's knikolla's intent20:27
gmannthat 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 branches20:29
gmann'extended-maintenance-new-requirements' this one 20:29
dansmithright, I'm just saying I think that's knikolla's intent20:30
dansmithit sounds like we're coalescing around this new one, so perhaps he can update the sibling now20:30
dansmith(or fold it in)20:30
gmannI 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
gmannsure,  am ok with that20:31
rosmaitagmann: dansmith: what do you think of this?  https://etherpad.opendev.org/p/openstack-unmaintained-transition20:31
knikollaI can either revise. Just didn't want to hold up one or the other based on implementation details that are separate. 20:31
dansmithrosmaita: yeah I think I said I was good with it20:33
gmannrosmaita: 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 upgradable20:33
dansmitheither we can fold that into this, or (what I assumed would happen is) knikolla can replace the sibling content with basically this20:33
dansmithI 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 approach20:34
gmanndansmith: knikolla: ok for me. so what will be proposal for those ? 20:34
gmannkeeping them in unmaintained pahse for a cycle to give time for maintainers who need them to opt-in those manually ?20:35
knikollaSince we seemed to have reached consensus I'm okay folding it in to reduce churn and merge conflicts. 20:35
dansmithknikolla: ack so that would probably reduce confusion at this point20:35
knikollaEveryone ok with the latest 3 EM branches transitioning to Unmaintained and keeping a rolling window of 3 until we have SLURP?20:36
gmannyeah, in case community does not read the other one.20:36
rosmaitaknikolla: you mean v/w/x  or x/w/y  ?20:37
gmannknikolla: ok with me.20:37
gmannv/w/x i think as per current EM20:37
knikollawe don't have yoga yet, so V/W/X20:37
gmannand then w/x/y once yoga move out of 'Maintained' phase20:37
gmannyeah20:37
knikollaonce Yoga is out, projects will have the option to opt-in to keep it. 20:37
rosmaitaok, cinder has already proposed to eol them all, so i guess i don't care20:38
gmann++20:38
gmannthis way we give them chance who need then to come forward and maintain 20:38
gmann*them20:38
knikollaOpt-out is totally okay :) rosmaita 20:38
rosmaitasounds good ... there has been no response to my "last call" email: https://lists.openstack.org/pipermail/openstack-discuss/2023-July/034346.html20:40
rosmaitado we have any remaining concerns about coordinated guidelines for EOL-ing branches across projects?20:42
knikollaWe're still basically saying you're on your own if a project you depend on isn't doing EM/Unmaintained.20:48
opendevreviewKristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance  https://review.opendev.org/c/openstack/governance/+/88877120:53
opendevreviewKristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance  https://review.opendev.org/c/openstack/governance/+/88877120:56
gmannrosmaita: 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 cinder21:04
gmannknikolla: 1 comment (for consistency reading of who will opt-in) otherwise this lgtm.21:08
opendevreviewKristi Nikolla proposed openstack/governance master: Unmaintained status replaces Extended Maintenance  https://review.opendev.org/c/openstack/governance/+/88877121:11

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!