<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white" class="ContentPasted0">Hi,</span>
<div style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white">
<br class="ContentPasted0">
</div>
<div style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white" class="ContentPasted0">
Thanks, Brian, for sharing Cinder team's view on this topic! I was thinking what to do now, and, because I agree that Rocky (and Stein, too) is probably a done business already, I'm planning to propose the rocky-eol patches for projects that are still open,
and teams can signal their decision on those patches (such as: +1 to EOL their stable/rocky branch, or -1 to keep it open).</div>
<div style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white">
<br class="ContentPasted0">
</div>
<div style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white" class="ContentPasted0">
Thanks again for the responses,</div>
<div style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white">
<br class="ContentPasted0">
</div>
<span style="font-size: 12pt; color: black; background-color: white;" data-ogsc="black" data-ogsb="white" class="ContentPasted0">Előd</span><br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Brian Rosmaita <rosmaita.fossdev@gmail.com><br>
<b>Sent:</b> Wednesday, April 12, 2023 6:49 PM<br>
<b>To:</b> openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org><br>
<b>Subject:</b> Re: [all][stable][ptl] Propose to EOL Rocky series</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 3/28/23 2:34 AM, Elõd Illés wrote:<br>
> Hi,<br>
> <br>
> this thread was bit of forgotten, sorry for that. A bit more than two<br>
> weeks ago we had a discussion on #openstack-release about this [1].<br>
> <br>
> So, to summerize, there are the issues:<br>
> - stable/rocky's gate is mostly broken<br>
> - more than one third of the repositories have transitioned their<br>
> stable/rocky branch to EOL (including multiple core component)<br>
> - old, unmaintained CI jobs, testing environments, hinders refactoring<br>
> of Zuul jobs and other configurations<br>
> <br>
> On the other hand, as Thomas mentioned, there is the need for some<br>
> to be able to cooperate (as an example: recent security issue [2],<br>
> mentioned in previous mail or in our IRC discussion) on a common place,<br>
> namely in gerrit.<br>
<br>
The Cinder project team discussed this at the 2023.2 Bobcat vPTG and <br>
decided that we will definitely EOL rocky AND stein. Given that other <br>
core projects have already done this, they've outlived their usefulness, <br>
even if they were only to be used to discuss patches for those branches <br>
in gerrit. If a cinder patch requires patches in other services that <br>
have EOL'd that branch, that other service's patches can't be discussed <br>
in gerrit. (And if there's an alternative place to discuss, for <br>
example, a nova rocky patch, then that alternative place can be used to <br>
discuss cinder EOL patches, too.)<br>
<br>
> This was originally the intention with Extended<br>
> Maintenance. We just haven't thought about eternity :)<br>
<br>
We are also concerned about the eternal nature of older branches. There <br>
are some open source projects where the convention has been to never <br>
delete a branch, even though at a certain point, no changes will be <br>
accepted into such a branch. OpenStack, however, is not such a project, <br>
and we *do* delete branches. There's a feeling among the project team <br>
that while a branch exists, we are still responsible for it, and there's <br>
an expectation that (no matter what the EM docs say), the project team <br>
is keeping an eye on it. So we support the current <br>
declare-EOL-and-delete-the-branch policy.<br>
<br>
Additionally, if we leave a branch in EM but turn off all CI because the <br>
team has no intention of ever merging anything into that branch, using <br>
gerrit for discussion of patches is probably unworkable as you start to <br>
get a bunch of patches into merge conflict, and it looks like the whole <br>
situation will just become a mess.<br>
<br>
> It seems that teams feel that if a branch is 'open' and in 'Extended<br>
> Maintenance' then it still means it is 'fully supported', thus cannot<br>
> let the gate failing AND don't want to merge patches without gate<br>
> tests, that's one reason why teams rather EOL their branches.<br>
<br>
We agree. "Not fully supported but still maintained" is a weird state. <br>
The way OpenStack has signaled "no more" for a branch is to delete it, <br>
so we continue to support the eol-and-delete policy.<br>
<br>
> We might need to think more about what is the best way forward.<br>
<br>
We think that rocky and stein are done deals because some projects have <br>
already deleted them. The next issue is train ... is it even <br>
responsible to have a branch that supports Python 2 be in extended <br>
maintenance? We agree that this requires some more thought.<br>
<br>
> [1] <br>
> <a href="https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2023-03-08.log.html#t2023-03-08T13:54:34">
https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2023-03-08.log.html#t2023-03-08T13:54:34</a><br>
> [2] <a href="https://security.openstack.org/ossa/OSSA-2023-002.html">https://security.openstack.org/ossa/OSSA-2023-002.html</a><br>
> <br>
> Előd<br>
> irc: elodilles<br>
> <br>
> ------------------------------------------------------------------------<br>
> *From:* Thomas Goirand <zigo@debian.org><br>
> *Sent:* Tuesday, February 14, 2023 7:31 PM<br>
> *To:* Elõd Illés <elod.illes@est.tech><br>
> *Cc:* openstack-discuss@lists.openstack.org <br>
> <openstack-discuss@lists.openstack.org><br>
> *Subject:* Re: [all][stable][ptl] Propose to EOL Rocky series<br>
> On 2/10/23 18:26, Elõd Illés wrote:<br>
>> Hi,<br>
>> <br>
>> thanks for all the feedbacks from teams so far!<br>
>> <br>
>> @Zigo: Extended Maintenance process was created just for the same <br>
>> situation: to give space to interested parties to cooperate and keep <br>
>> things maintained even when stable releases are over their 'supported' <br>
>> lifetime. So it's good to see that there is interest in it! <br>
>> Unfortunately, with very old branches we've reached the state where <br>
>> gates can't be maintained and without a functional gate it's not safe to <br>
>> merge patches (yes, even security fixes) and they are just using <br>
>> resources (CI & maintainers' time). When gate is broken in such extent, <br>
>> then i think the community have to accept that it is not possible to <br>
>> merge patches confidently and needs to EOL that release.<br>
> <br>
> That's where I don't agree. There are ways, outside of the OpenStack<br>
> gate, to test things, in such ways that merging patches there can be a<br>
> thing.<br>
> <br>
>> Another aspect is that code cannot be cleaned up until those old <br>
>> branches are still present (CI jobs, project configurations, etc) which <br>
>> gives pain for developers.<br>
> <br>
> Just disable gating completely then.<br>
> <br>
>> So, however some vendors would appreciate probably to keep things open <br>
>> forever, for the community this is not beneficial and doable I think. <br>
> <br>
> I don't agree. We need a place to share patches between distros. The<br>
> official Git feels like the natural place to do so, even without any<br>
> type of gating.<br>
> <br>
> BTW, my Nova patches for CVE-2022-47951 in Rocky, Stein & Train are<br>
> currently wrong and need another approach. I was thinking about simply<br>
> disabling .vmdk altogether (rather than having a complicated code to<br>
> check for the VMDK subtype). I wonder what other distros did. Where do I<br>
> disucss this?<br>
> <br>
> Cheers,<br>
> <br>
> Thomas Goirand (zigo)<br>
> <br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>