<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 7, 2023 at 10:23 AM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
 ---- On Tue, 06 Jun 2023 12:48:43 -0700  Jeremy Stanley  wrote --- <br>
 > On 2023-06-06 12:17:23 -0700 (-0700), Ghanshyam Mann wrote:<br>
 > [...]<br>
 > > This is true but I think this is the point where things are<br>
 > > becoming difficult. Even we do not need to but we as community<br>
 > > developers keep fixing the EM gate, at least I can tell from my QA<br>
 > > experience for this. We should stop at some line but in reality,<br>
 > > we end up doing it.<br>
 > [...]<br>
 > <br>
 > Maybe my verbosity made it unclear, so just in case, what I was<br>
 > trying to say is that I consider Extended Maintenance to be a failed<br>
 > experiment and agree we should be talking about either reverting to<br>
 > the prior process from before EM was a thing or finding an<br>
 > alternative process that doesn't have so many of the obvious<br>
 > shortcomings of EM.<br>
 > <br>
 > People said if we just stopped EOL'ing branches so soon they would<br>
 > show up and help make use of those branches. They didn't, and so the<br>
 > expected benefits never materialized.<br>
<br>
I agree. If I see the main overhead in EM maintenance is keeping testing green.<br>
it is not easy to keep 11 branches (including Em, supported stable and master)<br>
testing up to date. My point is if we remove all the integration testing (can keep pep8<br>
and unit tests) at the time the branch move to EM will solve the problem that the upstream<br>
community faces to maintain EM branches. <br></blockquote><div><br></div><div><br></div><div>This, IMO, is akin to retiring the branches. How could I, as a developer, patch an older version of a branch against a vulnerability of the style of the recent Cinder one, where the impact is felt cross-project, and you clearly need a working dev environment (such as devstack). </div><div><br></div><div>If, as you propose, we stopped doing any integration testing on branches older than 18 months, we would be de-facto retiring the integration testing infrastructure, which shares a huge amount of DNA with our dev tooling infrastructure.<br></div><div><br></div><div>I don't know what the answer is; but this as a middle ground seems like the worst of all worlds: the branches still exist, and we will not have the tools to (manually, not just CI) test meaningful changes on them.</div><div><br></div><div>Just a thought! </div><div><br></div><div>-</div><div>Jay Faulkner</div><div>Ironic PTL</div></div></div>