Monday, 2022-10-03

*** diablo_rojo is now known as Guest202501:46
*** amoralej|off is now known as amoralej06:12
*** diablo_rojo is now known as Guest209308:04
*** marios is now known as marios|call08:47
*** marios|call is now known as marios09:04
opendevreviewElod Illes proposed openstack/releases master: Zed final releases for cycle-with-rc projects  https://review.opendev.org/c/openstack/releases/+/86001110:22
*** dviroel_ is now known as dviroel11:40
opendevreviewElod Illes proposed openstack/releases master: Mark Zed as released  https://review.opendev.org/c/openstack/releases/+/86002911:46
opendevreviewAlfredo Moralejo proposed openstack/releases master: New release of puppet-swift for Yoga  https://review.opendev.org/c/openstack/releases/+/85993713:39
*** dviroel is now known as dviroel|lunch15:11
*** amoralej is now known as amoralej|off15:48
*** marios is now known as marios|out15:51
*** diablo_rojo is now known as Guest215316:08
*** dviroel|lunch is now known as dviroel16:38
*** Guest2153 is now known as diablo_rojo16:55
JayFHey folks o/ I'm curious about how difficult it'd be to push a patch release from Ironic's bugfix/[] branches. It was indicated to me this might be a manual process (and different from cutting patch releases from supported-integrated release branches)18:10
clarkbit doesn't look like ironic's gerrit acl delegates any project specific perms to push tags https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/ironic.config18:14
clarkbassuming that a manual process is necessary I believe that means a release manager will need to tag the repo and push the tag. Or the acl will need to be modified to allow ironic to do it18:14
JayFThat sounds roughly like what I was told would be needed (a human creating a tag). 18:15
clarkbthe manual process isn't too bad. YOu git tag -s the proper commit (double check the commit is known by gerrit first). Then git push the tag to gerrit. Then assuming your jobs are configured properly zuul should run off and build the artifacts and publish them for that version18:16
JayFAight; I'll follow process here https://releases.openstack.org/reference/using.html#requesting-a-release and request releases of all ironic stable branches with changes (including bugfix/*) branches. Please let me know if there's something I push that's not accurate; this is my first time doing this :D 18:17
clarkbas far as why this would require a manual push I wonder if the problem is in release tooling verification? Otherwise I don't think this is different than any other release18:18
JayFI honestly don't know; I was told it was a manual process so I thought I'd ask before requesting to ensure I'm not creating onerous amounts of work for others :)18:19
JayFclarkb: docs are unclear; is it a problem if I push a large number of releases in a single gerrit review? 19:24
* JayF is releasing stable patch releases ironic/ironic-inspector/ironic-python-agent/metalsmith from wallaby thru yoga19:25
JayFIn lieu of additional information; I'm going to do one review per project19:28
JayFscratch that, going to just do one PR, it's simpler if it's okay19:29
opendevreviewJay Faulkner proposed openstack/releases master: Release stable branches from w-y for Ironic projects  https://review.opendev.org/c/openstack/releases/+/86012519:31
*** dviroel is now known as dviroel|afk19:37
clarkbJayF: I'm not an expert on the release tooling but I think it is ok19:45
JayFAwesome. 19:45
JayFAlso, afaict, there is no way for me to git-request the tags for the Ironic bugfix/[] branches19:45
JayFdid I miss something, or should I do that via email to the releases team?19:45
JayFHmm. I see it now19:47
JayFah, they are listed but no real way to request a release19:57
clarkbNot sure this is the correct venue, but I wonder why do the bugfix releases need to live beyond the point in time where there is a subsequent stable release20:07
clarkbseems like the bugfix releases should get supplanted by the stable releases20:07
clarkbotherwise what you actually have is a second set of stable releases and maybe the best way to deal with those is to call them stable and treat them like every other stable release20:07
JayFclarkb: Ironic has a set of users who use Ironic without integration with large amounts of other OpenStack projects (such as metal3). The bugfix/ intermediate releases are cut for these projects, and we maintain them and backport almost everything that goes in stable/() to the bugfix/() branches as well20:09
JayFWe have a lot of known consumers of downstream releases dervived from those bugfix branches; there was some question in Ironic community if releases are similar consumed.20:10
clarkbright I undersatnd that20:10
clarkbwhat I'm saying is why can't they use the stable releases once they are cut20:10
JayFSo I took the step of looking at actual pypi download data:20:10
clarkbbasically the bugfix release comes out before stable/foo20:11
JayFclarkb: because those introduce new features/deprecations whereas the bugfix/[] is a point in time cut20:11
clarkbwhen stable/foo exists delete the bugfix release and move to stable/foo20:11
clarkbJayF: right in that case you have extra stable releases lets call them that20:11
clarkband then maybe we can make the tooling work to support the use case20:11
JayFI do not love the naming as it exists; but the naming is not something I chose or really was around to collab with.20:11
clarkbbasically either these are stable releases and the feature set and careful curation of fixes is important or they are not and you can upgrade to a stable release when it exists20:11
JayFYour sentiment is *exactly* why I'm looking to cut these releases.20:12
JayFI was frustrated we treated them as stable releases, but then only really gave access to those bugfixes to deployers sophisticated enough to pull them from git20:12
JayFor customers of downstream packagers who integrated those fixes from git20:12
clarkbah that makes sense20:12
JayFI'm trying to ensure this effort is available to all users of Ironic, so I'm trying to get actual-releases cut20:13
JayFI am somewhat expecting some number of "WTF" and "please help fix the tooling" responses, but requesting something be done in a nonideal way is often the best path to learning the ideal way :D20:13
clarkbI think if I were a user and I saw that ironic has bugfix and stable releases I would be wary of using bugfix releases if what I wanted was a stable release20:13
JayFI think the users of Ironic outside of OpenStack don't view it as stable / bugfix branches, they just see version numbers and pin20:14
clarkbthe other upside to using consistent terminology is that tools built around the terminology will suddenly work (though I grant there may be confusion over what the stable branch names should be)20:16
clarkbin the past ironic has struggled with mapping bugfix branches onto other branches of other software. Zuul by default maps to your default branch if there isn't a 1:1 match across repos20:16
clarkbso bugfix/old that is roughly stable/foo gets tested with master of other stuff instead of stable/foo20:16
JayFWe do have patches up that ... carefully curate that20:17
JayFbut it's mostly humans moving CI configs around, not really automation20:17
JayFand I had to -1 one today b/c it was missing something20:17
clarkbright its totally doable to override it. but if you align things by default then in theory a lot of that manual curation goes away20:17
clarkbBut I'm not sure how you align things if everyone else is not having a stable/foo.520:17
clarkbI'd have to think about that a bit more20:17
JayFyeah exactly, and I think that might be why it's named differently20:18
JayFI know how it is today, I don't know *why* it was done that way20:18
JayFfor that I'd have to do some historical reading20:18
opendevreviewDouglas Mendizábal proposed openstack/releases master: Update Barbican release liaison  https://review.opendev.org/c/openstack/releases/+/86015220:29
JayFclarkb: ... sometimes I wonder if you're clairvoyant21:27
JayFclarkb: https://zuul.opendev.org/t/openstack/config-errors 21:27
JayFironic is on this list, for disused bugfix branches21:27
JayFwhich have no real retirement process afaict21:28
clarkbya I think that is something ironic may still need to sort out (the retirement process for those branches)21:34

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!