| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-01 | |||
| 10:44:09 | kashyap | That's what I mean by a simple 1-line summary of the feature :) | |
| 10:44:13 | gibi | sean-k-mooney: "will automatically identify which commits are safe to modify, and which staged changes belong to each of those commits" this sounds dangerous | |
| 10:44:17 | bauzas | sean-k-mooney: well, I trust in Gerrit for this | |
| 10:44:18 | kashyap | Yeah | |
| 10:44:23 | sean-k-mooney | so what it does is allow you to write one commit at the end of a patch chain that fixes all the review feedback | |
| 10:44:36 | bauzas | and I trust reviewers | |
| 10:44:45 | sean-k-mooney | then it will automaticly decomose it into may commits and aplly them as fixup via an interactive rebase | |
| 10:44:57 | kashyap | That sounds quite invasive to me | |
| 10:44:59 | bauzas | if you create a fixup patch, then the CI wouldn't like it | |
| 10:45:08 | gibi | I mean sometimes I cannot figure out correctly what local change goes to which commit in my branch so I don't trust the machine to do that :D | |
| 10:45:15 | sean-k-mooney | oh ya im not sure this is smart to use | |
| 10:45:35 | sean-k-mooney | but it was an interesting idea | |
| 10:45:35 | bauzas | I'd prefer to just continue to have a master branch that works | |
| 10:45:58 | stephenfin | bauzas: I think you're misunderstanding what this does | |
| 10:46:02 | sean-k-mooney | it basically takes each hunk in the current commit and trys to apply it to the oldest commit that does not cause a marge conflict | |
| 10:46:05 | gibi | I have a nice long commit chain already for pps in nova so I can actually test its smartness | |
| 10:46:20 | bauzas | stephenfin: explain me, then | |
| 10:46:55 | stephenfin | you've got e.g. a 15 patch series and changes are required in a few of them | |
| 10:47:14 | bauzas | yeah that's what i understood | |
| 10:47:16 | stephenfin | in the GH pull request workflow, you'd typically fix them all in one go and commit a single "fix all the comments" patch | |
| 10:47:29 | bauzas | yeah, hence my "I love Gerrit" for this | |
| 10:47:51 | stephenfin | this will decompose that single patch and merge the things back into whatever one of the previous 15 patches they belong to | |
| 10:48:05 | kashyap | stephenfin: I see the use-case here, though. But it requires great care when using it to quadruple-check things | |
| 10:48:29 | kashyap | It sounds very nice on paper :) | |
| 10:48:31 | stephenfin | yeah, it's much less useful for Gerrit where you're forced to think in terms of individual commits and use rebase extensively | |
| 10:48:47 | sean-k-mooney | kashyap: yep that is why by default it create the delta as patch that you then can merge with an interactive rebase | |
| 10:48:47 | lyarwood | yeah it's working around the bork'd nature of the PR workflow | |
| 10:48:59 | sean-k-mooney | yep | |
| 10:48:59 | bauzas | stephenfin: okay, then why it would be nice for our, then ? | |
| 10:49:14 | stephenfin | it wouldn't really, but that doesn't make it a bad tool | |
| 10:49:16 | lyarwood | git stash ftw | |
| 10:49:22 | bauzas | stephenfin: we can already provide a new patch per change | |
| 10:49:30 | sean-k-mooney | yep it kidof reminded me of https://docs.openstack.org/infra/git-restack/ | |
| 10:49:38 | stephenfin | and I don't see what impact this would have on a working master branch | |
| 10:49:46 | sean-k-mooney | although a different approch | |
| 10:49:48 | lyarwood | it's useful when you need to fix HEAD~$something up but at pointing at HEAD | |
| 10:49:58 | lyarwood | but are* | |
| 10:49:59 | stephenfin | lyarwood: yup, agree RE: borked PR workflow | |
| 10:50:04 | bauzas | honestly, I don't see *why* I'd need this new tool | |
| 10:50:09 | jkulik | in our GH workflow, we still rebase the changes into every commit even for multi-commit PRs. no tool necessary. git commit --fixup and git rebase -i | |
| 10:50:16 | sean-k-mooney | bauzas: im not saying you do | |
| 10:50:29 | sean-k-mooney | bauzas: just wondering if people had used it | |
| 10:50:32 | bauzas | stephenfin: I don't like it because it means that it's OK to have a patch having bugs | |
| 10:50:46 | bauzas | if the next patch fixes them | |
| 10:50:53 | gibi | lyarwood: I tend to prepare commits top of HEAD and then do an interactive rebase to meld them into the proper origin commit they belong | |
| 10:50:55 | stephenfin | jkulik: yup, which works for a change to a single patch. Trickier if you have changes that affect multiple patches | |
| 10:50:58 | bauzas | of course, you *can* squash both | |
| 10:51:17 | stephenfin | bauzas: sounds like your issue is with the PR workflow rather than this tool :) | |
| 10:51:20 | bauzas | but heh, you can *not* squash, and that's why I dislike | |
| 10:51:23 | lyarwood | gibi: yeah that's another way, I just find stash a little quicker for small things | |
| 10:51:23 | sean-k-mooney | bauzas: that not what the tool is enabling at all though so that is kind of irrelevent | |
| 10:51:25 | gibi | lyarwood: I guess instead of commits I could do stash | |
| 10:51:28 | bauzas | stephenfin: correct | |
| 10:51:30 | stephenfin | or rather the CI systems built on this workflow | |
| 10:51:44 | sean-k-mooney | gibi: i dont like stash because i have lost work that way | |
| 10:51:49 | bauzas | stephenfin: and that's why i said "I prefer the Gerrit workflow for this" | |
| 10:51:51 | gibi | sean-k-mooney: ditto | |
| 10:52:11 | stephenfin | Ah, okay. Given we were talking about the tool, I thought you were comparing the _tool_ to Gerrit | |
| 10:52:17 | jkulik | lyarwood: here's the bug you requested https://bugs.launchpad.net/nova/+bug/1930406 | |
| 10:52:17 | opendevmeet | Launchpad bug 1930406 in OpenStack Compute (nova) "parallel volume-attachment requests might starve out nova-api for others" [Undecided,New] | |
| 10:52:19 | stephenfin | which doesn't really make sense | |
| 10:52:19 | sean-k-mooney | i much prefer to either do an interactive rebase and fix inline or put patches on the end an move them | |
| 10:52:25 | lyarwood | jkulik: thanks | |
| 10:52:32 | bauzas | sean-k-mooney: gibi: well, I use git reflog in this case | |
| 10:52:43 | gibi | for the git absorb thingy, if it can do a smart split of the local changes then it might help me with the commit creation what I do manually with git add -p | |
| 10:52:47 | sean-k-mooney | bauzas: i dont think that works with stash | |
| 10:52:48 | lyarwood | ah yes the get out of jail free card that is reflog | |
| 10:52:59 | sean-k-mooney | if it does good to know | |
| 10:53:00 | bauzas | sean-k-mooney: nah, I prefer to commit | |
| 10:53:06 | lyarwood | yeah it doesn't with stash | |
| 10:53:13 | sean-k-mooney | ya so do i so i can use reflog if i mess things up | |
| 10:53:25 | stephenfin | trying to parse a reasonably complex reflog is *soo* much fun | |
| 10:53:27 | bauzas | anyway, me needs to lunch | |
| 10:54:07 | lyarwood | stephenfin: always helps when you're looking for something rather important that would take ages to rewrite ^_^ | |
| 10:54:19 | gibi | :D | |
| 10:54:22 | lyarwood | can't say I ever look at reflog when I'm relaxed | |
| 10:54:26 | stephenfin | touché | |
| 10:54:29 | sean-k-mooney | stephenfin: totes fun but 99% of the time when i need it i just need the sha that is a 2-3 lines form the top | |
| 10:55:07 | gibi | have you ever git pulled one repo into another? that is fun to realize later on :D | |
| 10:55:18 | sean-k-mooney | lyarwood: ya when i use it its oftehn to fix an unitential rebase with git reivew | |
| 10:55:25 | sean-k-mooney | gibi: yep | |
| 10:55:51 | sean-k-mooney | gibi: nova has a full copy of the openwrt sorce tree in it somewhere | |
| 10:55:57 | gibi | at some point I had placement back in nova :D | |
| 10:56:36 | sean-k-mooney | at least the gerrit version of it had at one point we may have eventually git gc that out of the public repos | |
| 10:57:13 | gibi | ohh so the central copy of nova had openwrt? nice! | |
| 10:57:48 | lyarwood | sounds like some kind of go project repo | |
| 10:58:18 | sean-k-mooney | yep thats something jaypipes told me a long time ago. i assume someone pushed a review where tehy acindtally commited it locally | |
| 10:58:40 | sean-k-mooney | but gerrit would keep that around forever as a result in the gerrit copy of the repo | |
| 10:59:20 | sean-k-mooney | you would have to manually purge the review ref to remove it | |
| 11:08:39 | opendevreview | Stephen Finucane proposed openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/c/openstack/nova/+/706295 | |
| 11:13:03 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Drop references to non-filter scheduler drivers https://review.opendev.org/c/openstack/nova/+/773645 | |
| 11:13:04 | opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Merge driver into manager https://review.opendev.org/c/openstack/nova/+/773644 | |
| 11:13:04 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Merge 'test_utils', 'test_scheduler_utils' https://review.opendev.org/c/openstack/nova/+/773646 | |
| 11:13:05 | opendevreview | Stephen Finucane proposed openstack/nova master: conf: Remove deprecated aliases https://review.opendev.org/c/openstack/nova/+/773647 | |
| 11:38:57 | opendevreview | norman shen proposed openstack/nova master: Saving security group to info_cache https://review.opendev.org/c/openstack/nova/+/786348 | |
| 11:42:15 | stephenfin | dead simple Python 3.10 prep patch here if anyone has 2 mins https://review.opendev.org/c/openstack/nova/+/790405 | |
| 11:45:15 | gibi | stephenfin: done | |
| 11:45:18 | stephenfin | ta | |
| 12:15:20 | opendevreview | Lee Yarwood proposed openstack/nova stable/wallaby: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/793956 | |
| 12:16:29 | opendevreview | Lee Yarwood proposed openstack/nova stable/victoria: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/793957 | |