| *** elodilles_pto is now known as elodilles | 07:01 | |
| opendevreview | Arnaud Morin proposed openstack/project-config master: Switch mistral stable branch management to mistral cores https://review.opendev.org/c/openstack/project-config/+/1013038 | 13:53 |
|---|---|---|
| opendevreview | Merged openstack/project-config master: Switch mistral stable branch management to mistral cores https://review.opendev.org/c/openstack/project-config/+/1013038 | 14:06 |
| opendevreview | Clark Boylan proposed openstack/ptgbot master: Update testing and container image to python3.14 https://review.opendev.org/c/openstack/ptgbot/+/1013090 | 16:24 |
| opendevreview | Will Szumski proposed openstack/project-config master: Add x/networking-mlnx-tempest-plugin https://review.opendev.org/c/openstack/project-config/+/1013093 | 16:37 |
| opendevreview | Will Szumski proposed openstack/project-config master: Add x/networking-mlnx-tempest-plugin https://review.opendev.org/c/openstack/project-config/+/1013093 | 16:58 |
| mikal | Who is a devstack core these days? It would be nice to get https://review.opendev.org/q/project:openstack/devstack+author:mikal@stillhq.com+is:open merged to unblock some of the later import memory fixes. | 21:36 |
| clarkb | there are a handful of people I brought it up in the qa channel earlier today and gmaan said he would look early next week | 21:37 |
| mikal | Ok. I rebase / repush on Tuesdays my time, so there will be some amount of churn if its not before then but such is life. | 21:37 |
| mikal | I'm starting to get confused in the state of the 68 patches that are pushed vs the ones which I've held back to not overwhelm people, so merging some stuff will make it all a bit less confusing. | 21:38 |
| clarkb | why do you rebase? | 21:40 |
| clarkb | that shouldn't be necessary unless there is a conflict | 21:41 |
| mikal | Lots of reasons. It helps me catch reasons things don't apply any more. It gives me fresh CI results. It reinforces to the team that I am waiting on for review that the patch series is still maintained. Otherwise I'd have patches which were uploaded a year ago which would be sitting at the very bottom of the review queue and would never ever merge. | 21:41 |
| mikal | It also shakes out a lot of flakey CI because I tend to deep dive on failures, although less so this week because work was a mess and I didn't have time. | 21:42 |
| clarkb | right but none of that requires a rebase. YOu can rerun CI without a rebase. Things can be reviewed to applicability without changing the git state. etc | 21:42 |
| clarkb | in any case rebasing should only be necessary if a conflict needs to be addressed. | 21:42 |
| mikal | I guess my response could be summarised as "I only rebased patches which haven't merged, so merging some patches now and then would reduce the size of the rebase" | 21:42 |
| mikal | If the alternative is to re-run CI anyways, and a rebase is relatively cheap to do, why wouldn't you do a rebase? | 21:44 |
| clarkb | because rebasing changes the git state which has a bunch of other knock on effects | 21:44 |
| clarkb | for example it can make reviewing changes harder because the interdiffs between patchsets will include unnecessary additional information | 21:44 |
| mikal | That would be more of a problem if I was experiencing reviews. | 21:45 |
| clarkb | I should say may include. It isn't the case that this alwaeys happens | 21:45 |
| clarkb | In particular I think gerrit will only show those updates if they happen to touch the same files as the rebased change. If changes happen in other files it ignores them in the diff renders | 21:46 |
| clarkb | anyway in general I think that unnecessary rebases make it more difficult for people to understand the iterative development of a change | 21:46 |
| clarkb | necessary rebases to address conflicts are unavoidable | 21:47 |
| clarkb | re getting reviews I've reviewed the devstack changes and asked other devstack cores to review them to and gotten a positive response that this will happen soon | 21:47 |
| clarkb | I understand that getting reviews is a constant problem btu I feel like we've done ok here? | 21:47 |
| mikal | The other reason I rebase is because this tooling originated with container image build stuff in Kolla, and I wanted / needed a more recent version of the containers for my test lab. So I'd pull the current state of upstream, apply my patches, build, and the push back to gerrit if the build worked. That's become simply how my patch maintenance | 21:47 |
| mikal | tooling works for everyting now after a couple of years of doing that. | 21:47 |
| mikal | clarkb: oh, I don't think devstack has done a bad job here, and neutron has definitely done a good job. My point is more my tooling is now build around a world in which I basically never get reviews, so my mental model of gerrit is that its a weekly snapshot of a much faster moving development environment. | 21:49 |
| clarkb | which is possibly introducing a negative feedback loop making it harder for things to get reviewed... | 21:50 |
| mikal | *shrug* | 21:50 |
| mikal | At some level this is not my problem. I've been to PTGs. I've gotten people to agree to do specific things if I do other specific things. I do my bits and then they simply don't do theirs. There isn't really anything I can do about that. So instead I go off and do my thing instead of waiting around, and gerrit gets a weekly rebase / update / | 21:51 |
| mikal | snapshot of whatever I am doing at the time. | 21:51 |
| mikal | Ultimately its up to the OpenStack projects as to if they want to take my code or not, but I would think the first step would be to read it and that's the hurdle we have failed to cross for the majority of my stuff. | 21:52 |
| mikal | To rephrase -- the reviewers are within their rights to not read my patches, but I am also within my rights to develop things and publish them as patches in case people want them. Unless I am somehow causing some significant shared infra degredation, and I would find that hard to believe compared to the number of patches that others are pushing, | 21:55 |
| mikal | then that doesn't seem unreasonable to me. | 21:55 |
| clarkb | nope I don't have any concerns that this is problematic from a CI infrastructure perspective. More just that it makes the human side of development potentially more difficult as the target is constantly moving | 21:56 |
| clarkb | and if rerunning tests is valuable then I think that should be done | 21:56 |
| mikal | That's fair. The rebase process is how I catch that underlying interfaces have changed and the patchset needs a rework. I find value in that. I would prefer the stuff to be merged so that I didn't have to maintain it like this, but until that happens I will just plod along like I have for the last couple of years. | 21:57 |
| mikal | Noting as well that all of that patch management stuff is public as well, just done outside of OpenStack land. | 21:58 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!