Thanks for your response Jay Yes the <branch>-eol tag is somewhat useful, but it doesn't appear to be created until the branch is removed.  There is no way for a downstream consumer to to prepare for the forthcoming branch deletion.  There is no way to avoid a period of breakage. I'd like to suggest the branches be 'frozen', as in accepting no further updates, and tagged with <branch>-eol, but otherwise allowed to continue to exist for several months if not a year. That would allow downstream projects a reasonable period to switch from branch to tag and avoid a period of breakage. Second point.  Is there a separate mailing list to announce major events such as EOL of a branch?  It's hard to pick such announcements out of a general mailing list. Scott On 2023-05-11 18:39, Jay Faulkner wrote:

** *CAUTION: This email comes from a non Wind River email account!* Do not click links or open attachments unless you recognize the sender and know the content is safe. Hey Scott,

Good news! It's all still there, just not as branches. When a branch is moved from "Extended Maintenance" (EM) to End of Life (EOL), we remove the branch but retain the git refs on a tag.[1] (e.g. https://opendev.org/openstack/ironic/src/tag/stein-eol <https://urldefense.com/v3/__https://opendev.org/openstack/ironic/src/tag/stein-eol__;!!AjveYdw8EvQ!apBHo-KzBygqt5lBcWQglBwJIGOdfH3sz3CcLWJ28X_9PFacGxLhRQnyyxD8ARoFb-md29v17QlQmDvFpQ$> is the tag representing Ironic stable/stein at the point of EOL).

Look for the `train-eol` tag on the projects you're struggling with, and that should be the git ref you're looking for. Hopefully your tooling is happy getting any git ref and not just a branch ref.

1: https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-li... <https://urldefense.com/v3/__https://docs.openstack.org/project-team-guide/stable-branches.html*end-of-life__;Iw!!AjveYdw8EvQ!apBHo-KzBygqt5lBcWQglBwJIGOdfH3sz3CcLWJ28X_9PFacGxLhRQnyyxD8ARoFb-md29v17QlQZtReEw$>

Thanks, Jay Faulkner Ironic PTL TC Vice-Chair

On Thu, May 11, 2023 at 3:20 PM Scott Little <scott.little@windriver.com> wrote:

Hello OpenStack community

I'm one of the members of the StarlingX community.  We've had a lot of stability issues with our ability to compile both our development branch and supported release branches these last few weeks.  It all traces back to the Train EOL. We weren't monitoring openstack mailing lists, and missed the EOL announcement.  We are actively moving off of Train, but aren't yet ready.

What's really causing us grief is that some sub-projects, e.g.heat and nova, have started deleting elements of Train, e.g. git branches.

Now please don't take this wrong.  Ending support for an old branch is a totally normal thing, and we accept that.  If StarlingX customers need support in that area, we'll provide it. However I would plea to you to NOT delete the elements of Train that allow other projects to compile old openstack releases, e.g. your gits branches.

Sincerely

Scott Little on behalf of StarlingX

Scott, I acknowledge and empathize with the pain -- I've operated OpenStack forks downstream at previous jobs and have had to push changes to swap from the branch to the EOL-tag. With that being said, I still wouldn't be in favor of that kind of change in policy, because the downsides -- such as it not being clear to contributors what branches were open for contribution -- are pretty high. We have an announcement list[1]. I don't think it's a bad idea to start publishing posts there when a branch changes support status. I'm curious what other contributors would think of this. Thanks, Jay Faulkner Ironic PTL TC Vice-Chair 1: https://lists.openstack.org/pipermail/openstack-announce/ On Fri, May 12, 2023 at 6:32 AM Scott Little <scott.little@windriver.com> wrote:

Thanks for your response Jay

Yes the <branch>-eol tag is somewhat useful, but it doesn't appear to be created until the branch is removed. There is no way for a downstream consumer to to prepare for the forthcoming branch deletion. There is no way to avoid a period of breakage.

I'd like to suggest the branches be 'frozen', as in accepting no further updates, and tagged with <branch>-eol, but otherwise allowed to continue to exist for several months if not a year. That would allow downstream projects a reasonable period to switch from branch to tag and avoid a period of breakage.

Second point. Is there a separate mailing list to announce major events such as EOL of a branch? It's hard to pick such announcements out of a general mailing list.

Scott

On 2023-05-11 18:39, Jay Faulkner wrote:

*CAUTION: This email comes from a non Wind River email account!* Do not click links or open attachments unless you recognize the sender and know the content is safe. Hey Scott,

Good news! It's all still there, just not as branches. When a branch is moved from "Extended Maintenance" (EM) to End of Life (EOL), we remove the branch but retain the git refs on a tag.[1] (e.g. https://opendev.org/openstack/ironic/src/tag/stein-eol <https://urldefense.com/v3/__https://opendev.org/openstack/ironic/src/tag/stein-eol__;!!AjveYdw8EvQ!apBHo-KzBygqt5lBcWQglBwJIGOdfH3sz3CcLWJ28X_9PFacGxLhRQnyyxD8ARoFb-md29v17QlQmDvFpQ$> is the tag representing Ironic stable/stein at the point of EOL).

Look for the `train-eol` tag on the projects you're struggling with, and that should be the git ref you're looking for. Hopefully your tooling is happy getting any git ref and not just a branch ref.

1: https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-li... <https://urldefense.com/v3/__https://docs.openstack.org/project-team-guide/stable-branches.html*end-of-life__;Iw!!AjveYdw8EvQ!apBHo-KzBygqt5lBcWQglBwJIGOdfH3sz3CcLWJ28X_9PFacGxLhRQnyyxD8ARoFb-md29v17QlQZtReEw$>

Thanks, Jay Faulkner Ironic PTL TC Vice-Chair

On Thu, May 11, 2023 at 3:20 PM Scott Little <scott.little@windriver.com> wrote:

...

Hello OpenStack community

I'm one of the members of the StarlingX community. We've had a lot of stability issues with our ability to compile both our development branch and supported release branches these last few weeks. It all traces back to the Train EOL. We weren't monitoring openstack mailing lists, and missed the EOL announcement. We are actively moving off of Train, but aren't yet ready.

What's really causing us grief is that some sub-projects, e.g.heat and nova, have started deleting elements of Train, e.g. git branches.

Now please don't take this wrong. Ending support for an old branch is a totally normal thing, and we accept that. If StarlingX customers need support in that area, we'll provide it. However I would plea to you to NOT delete the elements of Train that allow other projects to compile old openstack releases, e.g. your gits branches.

Sincerely

Scott Little on behalf of StarlingX

On Sat, 13 May 2023 at 00:35, Scott Little <scott.little@windriver.com> wrote:

Thanks for your response Jay

Yes the <branch>-eol tag is somewhat useful, but it doesn't appear to be created until the branch is removed. There is no way for a downstream consumer to to prepare for the forthcoming branch deletion. There is no way to avoid a period of breakage.

This doesn't help you for train, but may save you some headaches in the future? You can keep an eye out for <branch>-em tags arriving. They're created when a project moves into Extended Maintenance mode. That's a pretty good signal that downstream consumers should expect the branch to translation to -eol "soon". Soon is hard to define but essentially it's a 6 month warning. Tony.