After having done a number of merges, I have some feedback to share:
having that automated would indeed make life easier
if someone is really keen on a bugfix, the merge might still be done manually right away
sometimes there are hairy conflicts
So if we put this into place, we would need some new “kitchen duty” to
care for notifications on failed merges
check the result of merges that were done automatically
The former should be done timely, to not break/postpone following merges. The latter should be rather easy, since frequent merges should be smaller and thus easier to check. The good thing is, everyone can check that, so it’s easily distributed.
No, except “even flawless merges sometimes break things big time”. I’m reluctant to automating this… at least thoroughly looking at the merge is a must IMHO.
Yep agree here, there’s almost always something that needs to be adjusted when doing upmerges unfortunately. It might help having a button that would try and push a PR that could be checked before merging though.
Just an idea: I think it would help if upmerges could be done right after a pull request has been merged, because
the person who merged the pull request still has an idea about what has been changed and could easily spot merge errors
the merged code would be available in master much sooner
Would it be feasible to automatically create a pull request for the upmerge, assign it to the person who merged and then make sure that it’s tackled right away?
I actually like that idea, upmerging changes you have no idea about can be challenging. Also the more changes the less confident I usually am merging it. Additionally it should avoid more conflicts caused by missing release upmerges e.g. since we’d upmerge more frequently.
However if you’re merging a couple of changes, which is quite often the case, it would be a bit annoying having to approve all of the upmerges. So maybe it should wait a bit of time before doing so?