*** Adri2000_ is now known as Adri2000 | 07:55 | |
gnuoy | Hi there, I'm after a bit of advice if possible. There are a number of charm repositories that have branches stable/2023.1. I'd like to refresh them by merging master into stable/2023.1. It that possible ? I tried: git checkout gerrit/stable/2023.1; git merge --no-ff gerrit/main; git commit --amend; git push gerrit HEAD:refs/for/refs/heads/stable/2023.1 | 12:15 |
---|---|---|
gnuoy | But the push fails with: | 12:15 |
gnuoy | error: failed to push some refs to 'ssh://review.opendev.org:29418/openstack/charm-glance-k8s.git' | 12:15 |
gnuoy | ! [remote rejected] HEAD -> refs/for/refs/heads/stable/2023.1 (commit c844cd8: you are not allowed to upload merges) | 12:15 |
frickler | gnuoy: the usual path of action would be to do a cherry-pick on each individual change that was merged into master | 12:16 |
fungi | yes, at rc1 deliverable repositories have their stable branches created for the upcoming coordinated release (stable/2023.2). at that point, development on the next release (2024.1) can begin merging in master and anything that needs to be fixed in stable/2023.2 gets selectively cherry-picked into that branch | 12:19 |
gnuoy | In this case stable/2023.1 was cut, in error, too early and there are more changes then it is practical to cherry-pick | 12:22 |
fungi | gnuoy: did you create the stable branches, or were they created through central openstack release management? are there any tags on the stable branches or other divergence that makes them non-fast-forwardable to master? any open changes targeting that branch? if the answer to all of those is no, then it may make more sense to delete and recreate those branches instead | 12:23 |
gnuoy | fungi, that is just what i was thinking | 12:23 |
gnuoy | Is it still the case that I cannot delete the branches myself and it is a pain for you guys to do it? | 12:25 |
fungi | you could grant branch deletion to the charms-release team similar to what you see done for ironic-release in gerrit/acls/openstack/ironic.config | 12:27 |
fungi | i feel like we just had this discussion last week, but maybe it was someone else | 12:28 |
gnuoy | That sounds like a great plan, thanks | 12:32 |
fungi | gnuoy: ahh, yeah it wasn't you, but tinwood_ was inquiring about branch deletion for charms-release too (i think): https://meetings.opendev.org/irclogs/%23openstack-infra/%23openstack-infra.2023-09-28.log.html | 12:33 |
fungi | though in the context of cleaning up some very old stable branches | 12:33 |
gnuoy | ah, sorry for the duplication. | 12:34 |
fungi | no apologies needed, i guess just confer and decide who's pushing up the patch for that | 12:34 |
fungi | or let me know if it's already up for review and i missed it (i don't see it in a quick skim of open changes) | 12:35 |
fungi | and make sure freyes is on board with the idea since we'll want him to +1 it as charms ptl | 12:36 |
gnuoy | tinwood, will be doing it from a charm project pov whereas I am looking at it from a sunbeam project pov. So they may be distinct changes | 12:37 |
gnuoy | (I will catch up with him though) | 12:38 |
fungi | oh! when you said "charm repositories" i thought you meant openstack charms | 12:38 |
fungi | but yes, process is basically the same, just different acls | 12:38 |
fungi | though you'd obviously want it to be the sunbeam-release group with rights to delete branches on those | 12:39 |
frickler | it seems the sunbeam project mainly consists of charm-k8s-* repos, which I also found very confusing when I discovered it | 12:44 |
fungi | as i understand, sunbeam is a successor to openstack-charms, but using kubernetes as its deployment platform with juju charms for the management layer or something | 12:48 |
opendevreview | gnuoy proposed openstack/project-config master: sunbeam-release delete stable/* branches https://review.opendev.org/c/openstack/project-config/+/897018 | 12:49 |
gnuoy | Not sure if I'm being naive or if the change really is as simple as ^ | 12:51 |
cloudnull | Mornings 😉 | 12:52 |
fungi | cloudnull: welcome! nice to see you around again ;) | 12:52 |
cloudnull | good to be around again :D | 12:52 |
fungi | gnuoy: it might work there, it'll work for sure in the more general refs/heads/* section which would also broaden this to allow sunbeam-core the ability to delete any branches it has permission to create | 12:55 |
gnuoy | I'll catch up with the PTL and get their opinion | 12:55 |
opendevreview | gnuoy proposed openstack/project-config master: Allow sunbeam-release to branches https://review.opendev.org/c/openstack/project-config/+/897018 | 13:00 |
fungi | er, i meant sunbeam-release of course, but eys | 13:02 |
*** haleyb_out is now known as haleyb | 13:33 | |
opendevreview | Merged openstack/project-config master: Allow sunbeam-release to branches https://review.opendev.org/c/openstack/project-config/+/897018 | 13:44 |
opendevreview | Merged openstack/project-config master: Remove fedora image from dib status https://review.opendev.org/c/openstack/project-config/+/895865 | 22:24 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!