| *** amoralej|off is now known as amoralej | 07:21 | |
| frickler | the kolla team would like to provide more regular (like maybe monthly) stable releases, is there some existing tooling that could be used e.g. to propose release patches in a (semi)automated way? | 08:42 |
|---|---|---|
| elodilles | frickler: well, it depends. if they are not using the new-release command, then it will ease a bit their release :) if they are using already, then the answer is no o:) | 09:17 |
| frickler | elodilles: thx, I didn't know that tool yet, it might at least help a bit, thx. I guess doing more automation would be hindered by the problem of deciding whether to do bugfix vs. feature release | 09:24 |
| elodilles | frickler: yes, that is the case. though if i'm not mistaken deployments projects are not following strictly semver, so actually they bump MAJOR versions between series, and bumping MINOR version whenever they release another stable version (if i remember correctly...) | 09:38 |
| frickler | elodilles: latest kolla xena release is 13.0.1, so that doesn't seem to be true in general. | 09:40 |
| frickler | but I can discuss that within the team | 09:40 |
| opendevreview | Marios Andreou proposed openstack/releases master: Make final tripleo repos release for stable/victoria before EM https://review.opendev.org/c/openstack/releases/+/836921 | 09:43 |
| elodilles | frickler: hmm, i see. actually there is not so much deliverables for Kolla team, so it shouldn't be a big problem to follow SemVer | 09:43 |
| elodilles | frickler: actually there is the ' | 09:44 |
| elodilles | reno -q semver-next' | 09:45 |
| frickler | elodilles: yes, the situation is certainly different than when having umpteen puppet modules or cookbooks | 09:45 |
| elodilles | command | 09:45 |
| elodilles | that *suggests* a version bump too, based on the release notes | 09:45 |
| elodilles | that is usually a good pointer, but it should not be blindly followed | 09:45 |
| elodilles | for example it suggests a MAJOR version bump in case of 'upgrade notes' as it usually needed when there is a change that an operator needs to be aware of / take actions -- i.e. something probably not backward compatible | 09:47 |
| frickler | elodilles: oh, cool, another thing to learn, seems I've been using some pretty old reno so far that didn't even know about that option | 09:47 |
| elodilles | but there are teams that adds extra info in their upgrade notes and for them it is usually not really signals for a backward compatibility | 09:48 |
| elodilles | anyway, it is still a good pointer :) | 09:48 |
| elodilles | (not talking about that fact, that on stable, according to stable policy, shouldn't be any 'new feature', i.e. MINOR version bump) | 09:49 |
| elodilles | but still, there are changes that we considering as requires MINOR version bump on stable branch | 09:50 |
| elodilles | oh, and some cases 'reno -q semver-next' gives completely false numbers (numbers, less than the previous release) OR ends up in an exception o:) so there are bugs as well :/ | 09:52 |
| mgoddard | Hi elodilles, can we merge https://review.opendev.org/c/openstack/releases/+/836328 ? | 09:53 |
| mgoddard | the flag discussion could be continued in another patch, if you wish | 09:54 |
| elodilles | mgoddard: i'd rather leave out that flag if the release works without it. can we wait a bit until this patch merges? >>> https://review.opendev.org/c/openstack/project-config/+/836763 | 09:58 |
| elodilles | fungi clarkb : can you please review this patch? >> https://review.opendev.org/c/openstack/project-config/+/836763 | 09:59 |
| elodilles | mgoddard: of course, if this cannot merge soon, then let's just merge your patch. | 10:00 |
| elodilles | mgoddard: is this OK for you? | 10:00 |
| mgoddard | elodilles: ok, thanks. Let's try to get it merged today one way or the other | 10:02 |
| elodilles | mgoddard: ++ | 10:28 |
| mgoddard | elodilles, frickler: considering the automatic releases discussion, the simplest option to me seems to be a minor bump every time | 10:34 |
| mgoddard | the benefit of frequent releases to me outweighs strict use of minor/patch versions | 10:35 |
| mgoddard | (given the alternative of very infrequently releasing after GA) | 10:35 |
| frickler | elodilles: mgoddard: guess I can fast-track that patch, wasn't aware that it is blocking | 10:43 |
| frickler | also agree on the minor bump | 10:45 |
| mgoddard | thanks frickler | 11:00 |
| opendevreview | Mark Goddard proposed openstack/releases master: Release kolla, kolla-ansible and ansible-collection-kolla Yoga RC1 https://review.opendev.org/c/openstack/releases/+/836328 | 11:01 |
| *** dviroel|afk is now known as dviroel\ | 11:13 | |
| *** dviroel\ is now known as dviroel | 11:13 | |
| frickler | mgoddard: elodilles: seems that didn't help with the release type error | 11:26 |
| elodilles | frickler: indeed :/ | 11:27 |
| elodilles | then let's use either 'artifact-link-mode: none' or 'no-artifact-build-job' | 11:28 |
| elodilles | to tell you the truth i don't know which is better. both make the validation pass. | 11:29 |
| elodilles | openstack-ansible uses 'artifact-link-mode: none' and kayobe uses 'no-artifact-build-job' | 11:29 |
| elodilles | and the descriptons tell me nothing: https://releases.openstack.org/reference/using.html#deliverables-file-schema | 11:30 |
| elodilles | i thought adding ansible-collection-kolla to projects.yaml would help :/ | 11:34 |
| opendevreview | Mark Goddard proposed openstack/releases master: Release kolla, kolla-ansible and ansible-collection-kolla Yoga RC1 https://review.opendev.org/c/openstack/releases/+/836328 | 12:08 |
| *** amoralej is now known as amoralej|lunch | 12:11 | |
| opendevreview | Merged openstack/releases master: Final Designate release for Victoria https://review.opendev.org/c/openstack/releases/+/836886 | 12:18 |
| elodilles | hberaud ttx : if you have time, could you please revisit this: https://review.opendev.org/c/openstack/releases/+/836328 | 12:28 |
| elodilles | unfortunately the flag is still needed after we have added the project to project-config's projects.yaml | 12:29 |
| ttx | done | 12:29 |
| elodilles | thx \o/ | 12:29 |
| opendevreview | Merged openstack/releases master: Release kolla, kolla-ansible and ansible-collection-kolla Yoga RC1 https://review.opendev.org/c/openstack/releases/+/836328 | 12:37 |
| mgoddard | Thanks elodilles & ttx. Yoga here we come | 12:41 |
| *** amoralej|lunch is now known as amoralej | 13:04 | |
| elodilles | mgoddard: \o/ | 13:14 |
| *** dviroel is now known as dviroel|ruck | 14:14 | |
| *** dviroel|ruck is now known as dviroel|ruck|lunch | 15:28 | |
| tkajinam | hi. may I ask for some suggestions about https://review.opendev.org/c/openstack/releases/+/834465 ? this is needed to fix the broken Yoga release. | 15:57 |
| *** dviroel|ruck|lunch is now known as dviroel|ruck | 16:13 | |
| *** amoralej is now known as amoralej|off | 17:08 | |
| elodilles | tkajinam: i've commented on it, these kind of releases are not allowed in stable branches, though I understand the issue and tend to accept an exception for this. but I also need to double-check with the rest of the team | 17:14 |
| elodilles | (also, the situation is a bit easier (in my opinion) as we are removing a dependency and not adding) | 17:18 |
| *** dviroel|ruck is now known as dviroel|afk | 20:39 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!