Re: Gitlab merge workflow: reverse it?
On Thu, Jun 25, 2020 at 7:49 PM David Edmundson wrote: >> You have this button from commit page, not merge request page. >> >> https://i.imgur.com/9kgdpVy.png > > > Found it, that's perfect thanks. > > That's also a useful feature in the current workflow. > Seems you can cherry-pick a commit in a work/branch to a new merge request. > >> >> If you use git cherry-pick with -x option, git automatically adds this >> message in commit. > > > That's handy. Clearly it's a common workflow then. > >> >> > - without making people commit locally into stable, could it encourage >> > people to not test as much? >> >> I did not actually suggest using Web UI but using the git operation >> locally. And in fairness either way we do end up with one bit where >> thing is untested, > > > It was the use of the web UI that I thought might encourage it, as then > you're not even changing branches locally to test things. > You're right that changing the workflow doesn't necessarily mean changing > that. > > And yes, it's a problem already, which is why I don't want it getting worse! > > There's another advantage in this pattern we've not discussed yet. We can > commit something to master, test for a few days and only then decide to > cherry-pick to stable, that could potentially improve some things. That last point is very important. Provided that it will compile for sure... When Qt suggested doing this, it felt a bit weird but I guess it was more fear of the unknown than anything else. I'd say let's do this and see what happens. The biggest con I find is that it will be harder to track where fixes are. I do "git tag --contains commitid" quite often, but this will replicate the commits to the different places so it will be less useful. A small price to pay I guess. Aleix
Re: Gitlab merge workflow: reverse it?
> You have this button from commit page, not merge request page. > > https://i.imgur.com/9kgdpVy.png Found it, that's perfect thanks. That's also a useful feature in the current workflow. Seems you can cherry-pick a commit in a work/branch to a new merge request. > If you use git cherry-pick with -x option, git automatically adds this > message in commit. > That's handy. Clearly it's a common workflow then. > > - without making people commit locally into stable, could it encourage > > people to not test as much? > > I did not actually suggest using Web UI but using the git operation > locally. And in fairness either way we do end up with one bit where > thing is untested, > It was the use of the web UI that I thought might encourage it, as then you're not even changing branches locally to test things. You're right that changing the workflow doesn't necessarily mean changing that. And yes, it's a problem already, which is why I don't want it getting worse! There's another advantage in this pattern we've not discussed yet. We can commit something to master, test for a few days and only then decide to cherry-pick to stable, that could potentially improve some things. David
Re: Gitlab merge workflow: reverse it?
Hello! On Thu, Jun 25, 2020 at 03:59:10PM +0100, David Edmundson wrote: > Gitlab supposedly has a magic button for it just after a commit has landed > in master. > https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html > > Though I don't know how to trigger that in our UI. You have this button from commit page, not merge request page. https://i.imgur.com/9kgdpVy.png > cherry-pick backwards. > In principle I completely agree. > > I have a few fears, which I hope are all addressable. > > - we need some reference to the real commit. > > Qt adds > "(cherry picked from commit 6de0287d7c3aa4251fe6eb4f970d73ce11cf07fc)" > to the commit message automagically somehow in their workflow. If you use git cherry-pick with -x option, git automatically adds this message in commit. > - without making people commit locally into stable, could it encourage > people to not test as much? I did not actually suggest using Web UI but using the git operation locally. And in fairness either way we do end up with one bit where thing is untested, Currently, - Start with change in master -> should it go into stable? -> change branch -> accepted This workflow does not gurantee that developer tested it before changing target branch anyway. > > > For now I am proposing this change only for Plasma repositories if we > > like it, we can propose this workflow for rest of KDE repositories, but > > that needs discussions in kde-devel/kde-core-devel separately. > > > > Thoughts? > > > > I like consistency across KDE, otherwise it's very difficult for people who > contribute in N places. > We should at least email before we change, though we can still discuss > things here first. What I meant was, test-drive this for small amount of one or two plasma repositories and if that works better, we can then ask people for adapting changes across KDE giving example. > > David -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Gitlab merge workflow: reverse it?
On Thu, Jun 25, 2020 at 3:46 PM Bhushan Shah wrote: > Hello everyone! > > This is a proposal to change our workflow regarding release branches and > our merge workflow, > > # Current workflow > > - Current workflow is that we commit to stable branch and then merge it > upwords until master branch > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then > master > > # Proposed workflow > > - Proposed workflow is to instead commit all changes in master, and > cherry-pick related changes in the stable branch as needed > > Gitlab supposedly has a magic button for it just after a commit has landed in master. https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html Though I don't know how to trigger that in our UI. > # Why? > > We occasionally hit several issues with current workflow, > > - Merge conflicts when merging changes upwords > - Changes which are valid only for stable branch needs to be reverted in > master branches > - Accidential merges from the master branch to stable branch which needs > to be force-pushed > > It's worth noting that Qt also recently changed to merge to dev, cherry-pick backwards. In principle I completely agree. I have a few fears, which I hope are all addressable. - we need some reference to the real commit. Qt adds "(cherry picked from commit 6de0287d7c3aa4251fe6eb4f970d73ce11cf07fc)" to the commit message automagically somehow in their workflow. - without making people commit locally into stable, could it encourage people to not test as much? > For now I am proposing this change only for Plasma repositories if we > like it, we can propose this workflow for rest of KDE repositories, but > that needs discussions in kde-devel/kde-core-devel separately. > > Thoughts? > I like consistency across KDE, otherwise it's very difficult for people who contribute in N places. We should at least email before we change, though we can still discuss things here first. David
Gitlab merge workflow: reverse it?
Hello everyone! This is a proposal to change our workflow regarding release branches and our merge workflow, # Current workflow - Current workflow is that we commit to stable branch and then merge it upwords until master branch - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then master # Proposed workflow - Proposed workflow is to instead commit all changes in master, and cherry-pick related changes in the stable branch as needed # Why? We occasionally hit several issues with current workflow, - Merge conflicts when merging changes upwords - Changes which are valid only for stable branch needs to be reverted in master branches - Accidential merges from the master branch to stable branch which needs to be force-pushed For now I am proposing this change only for Plasma repositories if we like it, we can propose this workflow for rest of KDE repositories, but that needs discussions in kde-devel/kde-core-devel separately. Thoughts? -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
