[release][tc][neutron] how to EOL unofficial branches under offical repositories
Hi,
I have a question about how to mark stable branches as EOL when such branches were not part of official releases at the moment of corresponding releases but the repositories which contain them became official after the release.
One example happens in a repository under the neutron team. networking-odl is now part of the neutron governance but as of Ocata release it was not official. Ocata branches under the neutron stadium were marked as EOL recently, but networking-odl was not marked as EOL as it was not an official repository as of Ocata.
The openstack/releases repository handles official branches under a specific release, but all branches in official repositories are under control of the openstack/releases repo.
I wonder how we can mark stable/ocata branch of networking-odl repo as EOL and delete stable/ocata branch. What is the recommended way to mark such branches described above as EOL?
Thanks in advance, Akihiro Motoki (irc: amotoki)
Hello,
I think that you are more or less in the same situation as with `puppet-openstack-integration`.
Please have a look to this patch https://review.opendev.org/c/openstack/releases/+/798282
I think that we could do something similar and then remove the stale branches.
Let me know what you think about this.
Le jeu. 1 juil. 2021 à 14:45, Akihiro Motoki amotoki@gmail.com a écrit :
Hi,
I have a question about how to mark stable branches as EOL when such branches were not part of official releases at the moment of corresponding releases but the repositories which contain them became official after the release.
One example happens in a repository under the neutron team. networking-odl is now part of the neutron governance but as of Ocata release it was not official. Ocata branches under the neutron stadium were marked as EOL recently, but networking-odl was not marked as EOL as it was not an official repository as of Ocata.
The openstack/releases repository handles official branches under a specific release, but all branches in official repositories are under control of the openstack/releases repo.
I wonder how we can mark stable/ocata branch of networking-odl repo as EOL and delete stable/ocata branch. What is the recommended way to mark such branches described above as EOL?
Thanks in advance, Akihiro Motoki (irc: amotoki)
Yes, what Hervé wrote is a good approach. (Actually, the same issue was already discussed in another mail thread [1]). I also talked about this with Lajos Katona and he is planning to prepare the EOL process and the release patches as far as I know.
Thanks,
Előd
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/thread.html...
On 2021. 07. 01. 14:59, Herve Beraud wrote:
Hello,
I think that you are more or less in the same situation as with `puppet-openstack-integration`.
Please have a look to this patch https://review.opendev.org/c/openstack/releases/+/798282 https://review.opendev.org/c/openstack/releases/+/798282
I think that we could do something similar and then remove the stale branches.
Let me know what you think about this.
Le jeu. 1 juil. 2021 à 14:45, Akihiro Motoki <amotoki@gmail.com mailto:amotoki@gmail.com> a écrit :
Hi, I have a question about how to mark stable branches as EOL when such branches were not part of official releases at the moment of corresponding releases but the repositories which contain them became official after the release. One example happens in a repository under the neutron team. networking-odl is now part of the neutron governance but as of Ocata release it was not official. Ocata branches under the neutron stadium were marked as EOL recently, but networking-odl was not marked as EOL as it was not an official repository as of Ocata. The openstack/releases repository handles official branches under a specific release, but all branches in official repositories are under control of the openstack/releases repo. I wonder how we can mark stable/ocata branch of networking-odl repo as EOL and delete stable/ocata branch. What is the recommended way to mark such branches described above as EOL? Thanks in advance, Akihiro Motoki (irc: amotoki)
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://github.com/4383/ https://twitter.com/4383hberaud https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Thanks Herve and Előd, The approach suggested totally makes sense. Also good to hear that Lajos is always preparing it :)
Side note: When I am trying to address zuul configuration errors, I noticed the only way to address it in stable/ocata in networking-odl is to EOL the branch as we already EOL'ed the neutron stable/ocata branch and the jobs always fail.
Thanks, Akihiro
On Thu, Jul 1, 2021 at 10:17 PM Előd Illés elod.illes@est.tech wrote:
Yes, what Hervé wrote is a good approach. (Actually, the same issue was already discussed in another mail thread [1]). I also talked about this with Lajos Katona and he is planning to prepare the EOL process and the release patches as far as I know.
Thanks,
Előd
[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/thread.html...
On 2021. 07. 01. 14:59, Herve Beraud wrote:
Hello,
I think that you are more or less in the same situation as with `puppet-openstack-integration`.
Please have a look to this patch https://review.opendev.org/c/openstack/releases/+/798282
I think that we could do something similar and then remove the stale branches.
Let me know what you think about this.
Le jeu. 1 juil. 2021 à 14:45, Akihiro Motoki amotoki@gmail.com a écrit :
Hi,
I have a question about how to mark stable branches as EOL when such branches were not part of official releases at the moment of corresponding releases but the repositories which contain them became official after the release.
One example happens in a repository under the neutron team. networking-odl is now part of the neutron governance but as of Ocata release it was not official. Ocata branches under the neutron stadium were marked as EOL recently, but networking-odl was not marked as EOL as it was not an official repository as of Ocata.
The openstack/releases repository handles official branches under a specific release, but all branches in official repositories are under control of the openstack/releases repo.
I wonder how we can mark stable/ocata branch of networking-odl repo as EOL and delete stable/ocata branch. What is the recommended way to mark such branches described above as EOL?
Thanks in advance, Akihiro Motoki (irc: amotoki)
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
participants (3)
-
Akihiro Motoki
-
Előd Illés
-
Herve Beraud