opendevreview | Hervé Beraud proposed openstack/releases master: fix tooling to retrieve unbranched deliverables based release id https://review.opendev.org/c/openstack/releases/+/900751 | 09:24 |
---|---|---|
opendevreview | Hervé Beraud proposed openstack/releases master: release cliff for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900754 | 09:41 |
opendevreview | Hervé Beraud proposed openstack/releases master: release keystoneauth for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900755 | 09:47 |
opendevreview | Hervé Beraud proposed openstack/releases master: release keystonemiddleware for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900756 | 09:47 |
opendevreview | Hervé Beraud proposed openstack/releases master: release metalsmith for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900757 | 09:49 |
opendevreview | Hervé Beraud proposed openstack/releases master: release mistral-extra for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900758 | 09:50 |
opendevreview | Hervé Beraud proposed openstack/releases master: release neutron-lib for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900759 | 09:52 |
opendevreview | Hervé Beraud proposed openstack/releases master: release octavia-lib for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900760 | 09:54 |
opendevreview | Hervé Beraud proposed openstack/releases master: release os-brick for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900761 | 09:55 |
opendevreview | Hervé Beraud proposed openstack/releases master: release os-vif for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900762 | 09:57 |
opendevreview | Hervé Beraud proposed openstack/releases master: release osc-lib for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900763 | 09:57 |
opendevreview | Hervé Beraud proposed openstack/releases master: release oslo.context for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900764 | 09:58 |
opendevreview | Hervé Beraud proposed openstack/releases master: release oslo.i18n for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900765 | 10:00 |
opendevreview | Hervé Beraud proposed openstack/releases master: release oslo.log for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900766 | 10:01 |
opendevreview | Hervé Beraud proposed openstack/releases master: release oslo.messaging for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900767 | 10:02 |
opendevreview | Hervé Beraud proposed openstack/releases master: release oslo.vmware for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900768 | 10:05 |
opendevreview | Hervé Beraud proposed openstack/releases master: release ovsdbapp for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900769 | 10:05 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-aodhclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900770 | 10:06 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-cyborgclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900771 | 10:08 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-magnumclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900773 | 10:13 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-manilaclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900774 | 10:15 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-masakariclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900775 | 10:16 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-neutronclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900776 | 10:18 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-octaviaclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900777 | 10:19 |
opendevreview | Hervé Beraud proposed openstack/releases master: release python-venusclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900779 | 10:22 |
opendevreview | Hervé Beraud proposed openstack/releases master: release sushy for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900781 | 10:27 |
opendevreview | Hervé Beraud proposed openstack/releases master: release os-ken for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900782 | 10:32 |
opendevreview | Merged openstack/releases master: Version of the role was recently bumped in metadata https://review.opendev.org/c/openstack/releases/+/895654 | 12:01 |
rpittau | hello everyone, the ironic team is looking to automatize the retirement of the bugfix branches for its projects, we're wondering if tagging the branches as eol with a standard patch in the release repo would be enough to get them deleted afterwards | 14:00 |
elodilles | rpittau: afair, that is exactly what the release team wanted to avoid in the past (otherwise the eol tagging could be used similarly like on the stable branches) | 14:03 |
rpittau | elodilles: thanks, but my understanding is that this is what we're actually doing for the stable branches, we mark them eol and then they'r removed from the release management team, at least this is what docs say | 14:05 |
elodilles | that's right | 14:06 |
rpittau | bugfix branches are specified in the deliverables yaml files, so I guess they can also be tagged as eol in the same way | 14:07 |
rpittau | this is to avoid issues where they are recreated if not tagged as eol, like it happened recently | 14:08 |
rpittau | and also keep track of it :) | 14:08 |
elodilles | yepp, i understand the intention, and though it would put more review duty on release team, it could sort out issues i guess | 14:12 |
rpittau | consider that we create/retire 4 bugfix branches per year | 14:14 |
rpittau | at max | 14:14 |
elodilles | yes, it's far less than if release team should care about the releases from bugfix branches, that's true :) | 14:16 |
rpittau | the alternative would be building our own tools reusing what release already has and with no tracking, would be still quite manual and prone to errors/forgetfulness | 14:20 |
TheJulia | And also conflicts since two separate sources of truth | 14:29 |
elodilles | :S | 14:29 |
JayF | elodilles: what is a path you see to Ironic team automating this without putting additional undue effort on releases team? | 14:54 |
JayF | As I see it, the human errors in retiring our bugfix branches manually have probably already cost you all more time in churn and questions than approving a nonurgent change a quarter; but if that is a concern I'd like to know how to resolve it -- for technical (source of truth) and governance (integrated release) issues we can't really automate this elsewhere | 14:57 |
elodilles | JayF: i'm not really against it, i just said what i remember ("bugfix branches are the ironic team's responsibility") from the past :) also, i might remember wrongly o:) maybe the rest of the release team have more memories about this topic | 15:37 |
JayF | I am trying to orient myself to the future; I think there were asssumptions that have now been proven wildly wrong that maintaining a manual process would be OK. That's clearly not the case. I (personally) don't use bugfix branches; but I think it's important to reliably manage their lifecycle to prevent problems like zuul-config-errors; that's why I'm here trying to find a | 15:40 |
JayF | path to getting the automation hooked up. | 15:40 |
elodilles | and thanks for that :) automation is most of the times better than manual handling with human errors o:) | 15:43 |
JayF | As the human who likely errored in at least one case, yeah :D | 15:43 |
elodilles | :D | 15:44 |
elodilles | we do errors as we are humans :) | 15:44 |
elodilles | hberaud ttx : fyi, for the recent release-job-failure: it's only an issue with ansible-config_template's reno configuration (and i've proposed this workaround for them to avoid in the future: https://review.opendev.org/c/openstack/ansible-config_template/+/900807 ) | 16:01 |
ttx | noted! Slowly getting back to speed after the KubeCon trip last week. | 16:02 |
elodilles | :-o how was the conference? | 16:07 |
opendevreview | Riccardo Pittau proposed openstack/releases master: [WIP] Allow eol of bugfix branches https://review.opendev.org/c/openstack/releases/+/900810 | 16:55 |
ttx | elodilles: busy! | 18:06 |
elodilles | :) | 18:48 |
opendevreview | Brian Haley proposed openstack/releases master: release os-ken for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900782 | 19:17 |
opendevreview | Brian Haley proposed openstack/releases master: release python-neutronclient for caracal-1 milestone https://review.opendev.org/c/openstack/releases/+/900776 | 19:48 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!