[release][stable] stale old branches probably should be EOL'd
Hi Release Team, now that stable/ocata is mostly tagged with ocata-eol tag it turned out that there are repositories that did not have any deliverables in ocata (not even a yaml under deliverables/ocata in the release repository). In fact, I've checked and there are several examples from the past where repositories have old stable branches open [1] that should be $series-eol tagged and deleted in my understanding. I think these old stable branches were skipped accidentally during the old EOL processing, so I would suggest to tag these with $series-eol and then delete the old branches. I don't see any reason these branches should be kept open. But let me know if I miss anything! If we stick to the tagging + deletion, then the next question is how to achieve this. There are a couple of options: 1. use the existing tools: such as creating a yaml file under deliverables/$series/ and add the $series-eol tag for the given repositories (I understand that these are not 'real' deliverables, but does that cause any issue for us?) 2. implement some new mechanism, similar to option 1, but clearly indicate that the tagging does not create any deliverables 3. manual tagging + deletion I think the 1st option is the easiest and since we already have the whole process there, we can simply use the existing tool. So what do you think? - Is that OK to tag these open old stable branches with $series-eol tag and then delete them? - If yes, which option from the above list is acceptable, or what else can we do? Thanks for the answers/ideas in advance, Előd [1] http://paste.openstack.org/show/806995/
On 2021-06-28 20:03:48 +0200 (+0200), Előd Illés wrote: [...]
If we stick to the tagging + deletion, then the next question is how to achieve this. There are a couple of options:
1. use the existing tools: such as creating a yaml file under deliverables/$series/ and add the $series-eol tag for the given repositories (I understand that these are not 'real' deliverables, but does that cause any issue for us?) 2. implement some new mechanism, similar to option 1, but clearly indicate that the tagging does not create any deliverables 3. manual tagging + deletion
I think the 1st option is the easiest and since we already have the whole process there, we can simply use the existing tool.
So what do you think? - Is that OK to tag these open old stable branches with $series-eol tag and then delete them? - If yes, which option from the above list is acceptable, or what else can we do? [...]
My two cents, I think it's okay to tag those old branches and delete them, and I support option 1 as it helps create a bit of a breadcrumb trail for future reflection. As for how they got overlooked, I expect you're right. In the past, well before we had any real release automation and tracking, projects asked the Infra team to delete their old branches, and quite often did not provide a complete list. -- Jeremy Stanley
Hello, I was thinking that our tooling will fail with these deliverables addition and tagging but apparently that's not the case so I would suggest to follow the 1st solution (using the existing tools, such as creating a yaml file etc ). Le lun. 28 juin 2021 à 20:15, Jeremy Stanley <fungi@yuggoth.org> a écrit :
On 2021-06-28 20:03:48 +0200 (+0200), Előd Illés wrote: [...]
If we stick to the tagging + deletion, then the next question is how to achieve this. There are a couple of options:
1. use the existing tools: such as creating a yaml file under deliverables/$series/ and add the $series-eol tag for the given repositories (I understand that these are not 'real' deliverables, but does that cause any issue for us?) 2. implement some new mechanism, similar to option 1, but clearly indicate that the tagging does not create any deliverables 3. manual tagging + deletion
I think the 1st option is the easiest and since we already have the whole process there, we can simply use the existing tool.
So what do you think? - Is that OK to tag these open old stable branches with $series-eol tag and then delete them?
WFM
- If yes, which option from the above list is acceptable, or what else can
we do?
The first one. [...]
My two cents, I think it's okay to tag those old branches and delete them, and I support option 1 as it helps create a bit of a breadcrumb trail for future reflection.
As for how they got overlooked, I expect you're right. In the past, well before we had any real release automation and tracking, projects asked the Infra team to delete their old branches, and quite often did not provide a complete list. -- Jeremy Stanley
-- 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-----
---- On Tue, 29 Jun 2021 09:03:58 -0500 Herve Beraud <hberaud@redhat.com> wrote ----
Hello, I was thinking that our tooling will fail with these deliverables addition and tagging but apparently that's not the case so I would suggest to follow the 1st solution (using the existing tools, such as creating a yaml file etc).
Le lun. 28 juin 2021 à 20:15, Jeremy Stanley <fungi@yuggoth.org> a écrit : On 2021-06-28 20:03:48 +0200 (+0200), Előd Illés wrote: [...]
If we stick to the tagging + deletion, then the next question is how to achieve this. There are a couple of options:
1. use the existing tools: such as creating a yaml file under deliverables/$series/ and add the $series-eol tag for the given repositories (I understand that these are not 'real' deliverables, but does that cause any issue for us?) 2. implement some new mechanism, similar to option 1, but clearly indicate that the tagging does not create any deliverables 3. manual tagging + deletion
I think the 1st option is the easiest and since we already have the whole process there, we can simply use the existing tool.
So what do you think? - Is that OK to tag these open old stable branches with $series-eol tag and then delete them?
WFM
- If yes, which option from the above list is acceptable, or what else can we do?
The first one.
+1, tagging and deleting will cleanup the things. -gmann
[...]
My two cents, I think it's okay to tag those old branches and delete them, and I support option 1 as it helps create a bit of a breadcrumb trail for future reflection.
As for how they got overlooked, I expect you're right. In the past, well before we had any real release automation and tracking, projects asked the Infra team to delete their old branches, and quite often did not provide a complete list. -- Jeremy Stanley
-- Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://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-----
Thanks Ghanshyam, too! :) Előd On 2021. 06. 29. 17:59, Ghanshyam Mann wrote:
---- On Tue, 29 Jun 2021 09:03:58 -0500 Herve Beraud <hberaud@redhat.com> wrote ----
Hello, I was thinking that our tooling will fail with these deliverables addition and tagging but apparently that's not the case so I would suggest to follow the 1st solution (using the existing tools, such as creating a yaml file etc).
Le lun. 28 juin 2021 à 20:15, Jeremy Stanley <fungi@yuggoth.org> a écrit : On 2021-06-28 20:03:48 +0200 (+0200), Előd Illés wrote: [...]
If we stick to the tagging + deletion, then the next question is how to achieve this. There are a couple of options:
1. use the existing tools: such as creating a yaml file under deliverables/$series/ and add the $series-eol tag for the given repositories (I understand that these are not 'real' deliverables, but does that cause any issue for us?) 2. implement some new mechanism, similar to option 1, but clearly indicate that the tagging does not create any deliverables 3. manual tagging + deletion
I think the 1st option is the easiest and since we already have the whole process there, we can simply use the existing tool.
So what do you think? - Is that OK to tag these open old stable branches with $series-eol tag and then delete them?
WFM
- If yes, which option from the above list is acceptable, or what else can we do?
The first one.
+1, tagging and deleting will cleanup the things.
-gmann
[...]
My two cents, I think it's okay to tag those old branches and delete them, and I support option 1 as it helps create a bit of a breadcrumb trail for future reflection.
As for how they got overlooked, I expect you're right. In the past, well before we had any real release automation and tracking, projects asked the Infra team to delete their old branches, and quite often did not provide a complete list. -- Jeremy Stanley
-- Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://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-----
Thanks for the feedback Jeremy & Hervé! I will propose patches accordingly. Thanks, Előd On 2021. 06. 29. 16:03, Herve Beraud wrote:
Hello,
I was thinking that our tooling will fail with these deliverables addition and tagging but apparently that's not the case so I would suggest to follow the 1st solution (using the existing tools, such as creating a yaml file etc).
Le lun. 28 juin 2021 à 20:15, Jeremy Stanley <fungi@yuggoth.org <mailto:fungi@yuggoth.org>> a écrit :
On 2021-06-28 20:03:48 +0200 (+0200), Előd Illés wrote: [...] > If we stick to the tagging + deletion, then the next question is how to > achieve this. There are a couple of options: > > 1. use the existing tools: such as creating a yaml file under > deliverables/$series/ and add the $series-eol tag for the given repositories > (I understand that these are not 'real' deliverables, but does that cause > any issue for us?) > 2. implement some new mechanism, similar to option 1, but clearly indicate > that the tagging does not create any deliverables > 3. manual tagging + deletion > > I think the 1st option is the easiest and since we already have the whole > process there, we can simply use the existing tool. > > So what do you think? > - Is that OK to tag these open old stable branches with $series-eol tag and > then delete them?
WFM
> - If yes, which option from the above list is acceptable, or what else can > we do?
The first one.
[...]
My two cents, I think it's okay to tag those old branches and delete them, and I support option 1 as it helps create a bit of a breadcrumb trail for future reflection.
As for how they got overlooked, I expect you're right. In the past, well before we had any real release automation and tracking, projects asked the Infra team to delete their old branches, and quite often did not provide a complete list. -- Jeremy Stanley
-- 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-----
participants (4)
-
Előd Illés
-
Ghanshyam Mann
-
Herve Beraud
-
Jeremy Stanley