Re: Git merge workflow: reverse it?
On Tue, May 10, 2022 at 10:48 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > On 2022-05-10 15:33, Nate Graham wrote: > > On 5/10/22 04:15, Ingo Klöcker wrote: > >>> https://manifesto.kde.org/commitments/ > >> > >> I don't see anything in there that would force the same merge workflow > >> on all > >> KDE projects. In my view the merge workflow is comparable to the > >> coding style. > >> > >> Regards, > >> Ingo > > > > I don't think anyone is trying to force anything; rather, the proposal > > is to get voluntary consensus around standardizing on a single > > workflow (whatever it is) so that we all individually reap the > > benefits of consistency by not having to remember two workflows, look > > up which workflow a project uses, etc. > > > > Personally I don't care which one we standardize on, but I am in favor > > of voluntarily and communally standardizing on one of them. > > Yeah, I doubt we can or want to force people. > > I personally prefer the cherry-pick approach from master > to the stable branch(es), given I only work on the master branch and > that is for me the best way to previously test the stuff properly. > > Naturally for e.g. Kate we only backport trivial stuff that way. > KDiff3 is in much the same position. In addition, stable branches are not made on the rapid release schedule of KDE Applications. Meaning direct merge either to or from master may produce unexpected results. Even cherry picks sometimes need minor adjustment to work due to refactoring in master. > > Greetings > Christoph > > > > > Nate > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org >
Re: Git merge workflow: reverse it?
On 2022-05-10 15:33, Nate Graham wrote: On 5/10/22 04:15, Ingo Klöcker wrote: https://manifesto.kde.org/commitments/ I don't see anything in there that would force the same merge workflow on all KDE projects. In my view the merge workflow is comparable to the coding style. Regards, Ingo I don't think anyone is trying to force anything; rather, the proposal is to get voluntary consensus around standardizing on a single workflow (whatever it is) so that we all individually reap the benefits of consistency by not having to remember two workflows, look up which workflow a project uses, etc. Personally I don't care which one we standardize on, but I am in favor of voluntarily and communally standardizing on one of them. Yeah, I doubt we can or want to force people. I personally prefer the cherry-pick approach from master to the stable branch(es), given I only work on the master branch and that is for me the best way to previously test the stuff properly. Naturally for e.g. Kate we only backport trivial stuff that way. Greetings Christoph Nate -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: Git merge workflow: reverse it?
On 5/10/22 04:15, Ingo Klöcker wrote: https://manifesto.kde.org/commitments/ I don't see anything in there that would force the same merge workflow on all KDE projects. In my view the merge workflow is comparable to the coding style. Regards, Ingo I don't think anyone is trying to force anything; rather, the proposal is to get voluntary consensus around standardizing on a single workflow (whatever it is) so that we all individually reap the benefits of consistency by not having to remember two workflows, look up which workflow a project uses, etc. Personally I don't care which one we standardize on, but I am in favor of voluntarily and communally standardizing on one of them. Nate
Re: Git merge workflow: reverse it?
On Dienstag, 10. Mai 2022 11:48:30 CEST Harald Sitter wrote: > On Tue, May 10, 2022 at 10:59 AM Ingo Klöcker wrote: > > On Dienstag, 10. Mai 2022 09:36:17 CEST Kai Uwe Broulik wrote: > > > can we get an update on this? > > > > > > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and > > > frustrating when some projects use cherry-pick (e.g. Kate) and some > > > don't (e.g. Dolphin). > > > > > > I don't really mind what the outcome is but I need it to be consistent > > > and predictable where to target my MRs, at least for every domain > > > (Plasma, Gear, ..). > > > > I can imagine a consistent rule for Frameworks (if that's what you mean by > > "domain"). Apart from that I can only imagine a consistent rule per > > development team, e.g. Plasma team or PIM team, but not for Gear as a > > whole > > which is just a random mix of the products of different teams with > > different workflows. Of course, this doesn't stop the different > > development teams from adopting the same merge workflow. But this cannot > > be forced on all development teams. > > I'm sure we can, it's one of the technical pillars of the manifesto :) I wish top-posting was forbidden by the manifesto. ;-) > https://manifesto.kde.org/commitments/ I don't see anything in there that would force the same merge workflow on all KDE projects. In my view the merge workflow is comparable to the coding style. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Git merge workflow: reverse it?
I'm sure we can, it's one of the technical pillars of the manifesto :) https://manifesto.kde.org/commitments/ On Tue, May 10, 2022 at 10:59 AM Ingo Klöcker wrote: > > On Dienstag, 10. Mai 2022 09:36:17 CEST Kai Uwe Broulik wrote: > > can we get an update on this? > > > > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and > > frustrating when some projects use cherry-pick (e.g. Kate) and some > > don't (e.g. Dolphin). > > > > I don't really mind what the outcome is but I need it to be consistent > > and predictable where to target my MRs, at least for every domain > > (Plasma, Gear, ..). > > I can imagine a consistent rule for Frameworks (if that's what you mean by > "domain"). Apart from that I can only imagine a consistent rule per > development team, e.g. Plasma team or PIM team, but not for Gear as a whole > which is just a random mix of the products of different teams with different > workflows. Of course, this doesn't stop the different development teams from > adopting the same merge workflow. But this cannot be forced on all development > teams. > > Regards, > Ingo
Re: Git merge workflow: reverse it?
On Dienstag, 10. Mai 2022 09:36:17 CEST Kai Uwe Broulik wrote: > can we get an update on this? > > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and > frustrating when some projects use cherry-pick (e.g. Kate) and some > don't (e.g. Dolphin). > > I don't really mind what the outcome is but I need it to be consistent > and predictable where to target my MRs, at least for every domain > (Plasma, Gear, ..). I can imagine a consistent rule for Frameworks (if that's what you mean by "domain"). Apart from that I can only imagine a consistent rule per development team, e.g. Plasma team or PIM team, but not for Gear as a whole which is just a random mix of the products of different teams with different workflows. Of course, this doesn't stop the different development teams from adopting the same merge workflow. But this cannot be forced on all development teams. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Git merge workflow: reverse it?
Hi, can we get an update on this? Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and frustrating when some projects use cherry-pick (e.g. Kate) and some don't (e.g. Dolphin). I don't really mind what the outcome is but I need it to be consistent and predictable where to target my MRs, at least for every domain (Plasma, Gear, ..). Cheers Kai Uwe PS: Since I can never remember: it's git rebase --onto newbase oldbase branch Am 29.07.20 um 14:01 schrieb Bhushan Shah: Hello everyone! At plasma, we are experimenting with new workflow regarding how bugfixes are put on the stable branch [1]. # Previous 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 # Current workflow - Proposed workflow is to instead commit all changes in master, and cherry-pick related changes in the stable branch as needed - We had been using this workflow for about 1 month now and I'd say it is working nicely for us. # Why? We occasionally hit several issues with previous workflow, - Merge conflicts when merging changes upwords - Changes which are valid only for stable branch needs to be reverted in master branches. So you end-up with, stable-fix, revert of stable fix and then different fix and overall weird history. - Accidential merges from the master branch to stable branch which needs to be force-resetted. - It's worth noting that Qt also recently changed to merge to dev, cherry-pick backwards. - This also allows for workflows where we want to commit some bugfix in the master branch for few days/weeks and if it works fine in general testing then, cherry-pick it in stable branches. Proposal is to probably adapt this policy kde-wise if people feel that advantages are worth it. Thanks [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html
