Re: [Emc-developers] Merge Strategy
Yes that is an advantage in theory. though I think people are over stating that problem. The eventual cost is, error prone, slow to happen merges that only a couple developers can/will do. Hopefully we can gain a bunch more savvy developers and this would be a much smaller problem. Chris From: andy pugh Sent: November 30, 2022 12:11 PM To: EMC developers Subject: Re: [Emc-developers] Merge Strategy On Wed, 30 Nov 2022 at 12:04, Chris Morley wrote: I presented my idea to see if anyone could show a fatal flaw of it so I > appreciate the discussion/feedback. I think the only advantage of our current strategy (and it's not a good one) is that if things get forgotten then they will still be merged by accident when someone merges their own work, so less stuff gets lost. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
We could possibly establish a "forgotten but still pressing PR"-committee that submitters can call when they (I mean, their patches) feel neglected? Best, Steffen To be clear, I was discussing strategy of branch-to-branch merges not pull request merges. Chris ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
That video conferencing seemed helpful to have some older PRs looked into. We did not do it last time, but maybe any such routine would help. It is a complex software we are talking about one quickly is beyond one's immediate wits, shying away from that responsibility. So having many individual and experiences jointly looking at the same patch may be beneficial. And for the older PRs the responsible individuals (submitters) may not always be available, still. I suggest to release a nice version 2.9, and then have some talking about what we want for release 2.10/3.0 and how we should get there. I find that for the documentation this works very nice these days. Everyone knows that @hansu has a rigorous eye+judgement on what is submitted - and we/hansu know when to ask and everyone knows that we/hansu will ask when there is a need to get something clarified. Maybe we can have more such teams that address some distinct corner of LinuxCNC? We could possibly establish a "forgotten but still pressing PR"-committee that submitters can call when they (I mean, their patches) feel neglected? Best, Steffen > Gesendet: Mittwoch, 30. November 2022 um 13:00 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Our current strategy has not been always right in the past. > I have occasionally had to fix merges after the fact because someone merged > them wrong. > (People have occasionally had to fix my merge mistakes too.) > Which is not surprising considering the type of files I usually work on (XML). > I have had to wait for up merges to get needed work to master. > The conflicts you are talking of are probably because I put separate commits > in each branch because I was tired of waiting. > > Of course 2.9 to master will be easy for a while but the same problem will > come back. > Even more so if the Debian inclusion gives us many more pull requests from > non devs. > > I just think that having only about 4 devs that actually do merges is not a > good games plan. > I presented my idea to see if anyone could show a fatal flaw of it so I > appreciate the discussion/feedback. > So far no fatal flaw, other then it's different. > > But I also recognise I'm not convincing anyone so I guess I will try to let > it go :) > But again thanks for the discussion, that was the most important part! > > Chris > ____________ > From: andy pugh > Sent: November 30, 2022 10:24 AM > To: EMC developers > Subject: Re: [Emc-developers] Merge Strategy > > On Wed, 30 Nov 2022 at 07:38, Chris Morley > wrote: > > > > > The only solution, given our current strategy, is to wait/ask for someone > > else to fix it. > > This is the crux of the problem. > > > I think that our current merge-up strategy has been right in the past and > will be right again, but currently there are significant conflicts between > the tip of 2.8 and 2.9. These seem to be mainly docs and the fallout of me > merging 7i96S support "backwards". > > I think we need a one-off effort to make sure that there aren't any > important bug fixes in 2.8 needed in 2.9 but in general I think that the > outstanding commits should be marked as merged (for housekeeping reasons) > but with the code remaining as the 2.9 version unless there is an obviously > necessary fix. I think that in general this is going to mean just git > checkout --ours conflicted.file but with a look at the commit > description to see if a fix (possibly one different from either existing > file) is needed. > > Here is the conflict list. > > Auto-merging src/hal/drivers/mesa-hostmot2/pins.c > > CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/pins.c > > Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.h > > CONFLICT (content): Merge conflict in > src/hal/drivers/mesa-hostmot2/hostmot2.h > > Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.c > > CONFLICT (content): Merge conflict in > src/hal/drivers/mesa-hostmot2/hostmot2.c > > Auto-merging src/hal/drivers/mesa-hostmot2/hm2_eth.c > > Auto-merging src/emc/usr_intf/pncconf/private_data.py > > CONFLICT (content): Merge conflict in > src/emc/usr_intf/pncconf/private_data.py > > Auto-merging src/emc/usr_intf/pncconf/pncconf.py > > CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/pncconf.py > > Auto-merging src/emc/usr_intf/pncconf/build_HAL.py > > CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/build_HAL.py > > Auto-merging src/emc/usr_intf/gmoccapy/release_notes.txt > > CONFLICT (content): Merge conflict in > src/emc/usr_intf/gmoccapy/release_notes.txt > > Auto-me
Re: [Emc-developers] Merge Strategy
On Wed, 30 Nov 2022 at 12:04, Chris Morley wrote: I presented my idea to see if anyone could show a fatal flaw of it so I > appreciate the discussion/feedback. I think the only advantage of our current strategy (and it's not a good one) is that if things get forgotten then they will still be merged by accident when someone merges their own work, so less stuff gets lost. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
Our current strategy has not been always right in the past. I have occasionally had to fix merges after the fact because someone merged them wrong. (People have occasionally had to fix my merge mistakes too.) Which is not surprising considering the type of files I usually work on (XML). I have had to wait for up merges to get needed work to master. The conflicts you are talking of are probably because I put separate commits in each branch because I was tired of waiting. Of course 2.9 to master will be easy for a while but the same problem will come back. Even more so if the Debian inclusion gives us many more pull requests from non devs. I just think that having only about 4 devs that actually do merges is not a good games plan. I presented my idea to see if anyone could show a fatal flaw of it so I appreciate the discussion/feedback. So far no fatal flaw, other then it's different. But I also recognise I'm not convincing anyone so I guess I will try to let it go :) But again thanks for the discussion, that was the most important part! Chris From: andy pugh Sent: November 30, 2022 10:24 AM To: EMC developers Subject: Re: [Emc-developers] Merge Strategy On Wed, 30 Nov 2022 at 07:38, Chris Morley wrote: > > The only solution, given our current strategy, is to wait/ask for someone > else to fix it. > This is the crux of the problem. I think that our current merge-up strategy has been right in the past and will be right again, but currently there are significant conflicts between the tip of 2.8 and 2.9. These seem to be mainly docs and the fallout of me merging 7i96S support "backwards". I think we need a one-off effort to make sure that there aren't any important bug fixes in 2.8 needed in 2.9 but in general I think that the outstanding commits should be marked as merged (for housekeeping reasons) but with the code remaining as the 2.9 version unless there is an obviously necessary fix. I think that in general this is going to mean just git checkout --ours conflicted.file but with a look at the commit description to see if a fix (possibly one different from either existing file) is needed. Here is the conflict list. Auto-merging src/hal/drivers/mesa-hostmot2/pins.c CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/pins.c Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.h CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/hostmot2.h Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.c CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/hostmot2.c Auto-merging src/hal/drivers/mesa-hostmot2/hm2_eth.c Auto-merging src/emc/usr_intf/pncconf/private_data.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/private_data.py Auto-merging src/emc/usr_intf/pncconf/pncconf.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/pncconf.py Auto-merging src/emc/usr_intf/pncconf/build_HAL.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/build_HAL.py Auto-merging src/emc/usr_intf/gmoccapy/release_notes.txt CONFLICT (content): Merge conflict in src/emc/usr_intf/gmoccapy/release_notes.txt Auto-merging src/emc/usr_intf/gmoccapy/gmoccapy.py Auto-merging src/emc/usr_intf/gmoccapy/getiniinfo.py Auto-merging src/emc/usr_intf/emcrsh.cc Auto-merging src/Makefile Auto-merging share/qtvcp/panels/cam_align/cam_align_handler.py CONFLICT (content): Merge conflict in share/qtvcp/panels/cam_align/cam_align_handler.py CONFLICT (modify/delete): docs/src/gui/gmoccapy.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/gui/gmoccapy.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc_es.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc_es.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc-cn.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc-cn.txt left in tree. Auto-merging docs/man/man9/hostmot2.9 CONFLICT (content): Merge conflict in docs/man/man9/hostmot2.9 Auto-merging docs/man/man9/hm2_eth.9 Auto-merging debian/changelog CONFLICT (content): Merge conflict in debian/changelog Auto-merging VERSION CONFLICT (content): Merge conflict in VERSION warning: inexact rename detection was skipped due to too many files. warning: you may want to set your merge.renamelimit variable to at least 2086 and retry the command. Automatic merge failed; fix conflicts and then commit the result. pins.c, hostmot2.h, hostmot2.c, release_notes.txt, hostmot2.9, hm2_eth.9 changelog and VERSION should all be resolved by --ours. That leaves pncconf private_data.py, pnconf.py builf_HAL.py from pncconf. I
Re: [Emc-developers] Merge Strategy
On Wed, 30 Nov 2022 at 07:38, Chris Morley wrote: > > The only solution, given our current strategy, is to wait/ask for someone > else to fix it. > This is the crux of the problem. I think that our current merge-up strategy has been right in the past and will be right again, but currently there are significant conflicts between the tip of 2.8 and 2.9. These seem to be mainly docs and the fallout of me merging 7i96S support "backwards". I think we need a one-off effort to make sure that there aren't any important bug fixes in 2.8 needed in 2.9 but in general I think that the outstanding commits should be marked as merged (for housekeeping reasons) but with the code remaining as the 2.9 version unless there is an obviously necessary fix. I think that in general this is going to mean just git checkout --ours conflicted.file but with a look at the commit description to see if a fix (possibly one different from either existing file) is needed. Here is the conflict list. Auto-merging src/hal/drivers/mesa-hostmot2/pins.c CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/pins.c Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.h CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/hostmot2.h Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.c CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/hostmot2.c Auto-merging src/hal/drivers/mesa-hostmot2/hm2_eth.c Auto-merging src/emc/usr_intf/pncconf/private_data.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/private_data.py Auto-merging src/emc/usr_intf/pncconf/pncconf.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/pncconf.py Auto-merging src/emc/usr_intf/pncconf/build_HAL.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/build_HAL.py Auto-merging src/emc/usr_intf/gmoccapy/release_notes.txt CONFLICT (content): Merge conflict in src/emc/usr_intf/gmoccapy/release_notes.txt Auto-merging src/emc/usr_intf/gmoccapy/gmoccapy.py Auto-merging src/emc/usr_intf/gmoccapy/getiniinfo.py Auto-merging src/emc/usr_intf/emcrsh.cc Auto-merging src/Makefile Auto-merging share/qtvcp/panels/cam_align/cam_align_handler.py CONFLICT (content): Merge conflict in share/qtvcp/panels/cam_align/cam_align_handler.py CONFLICT (modify/delete): docs/src/gui/gmoccapy.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/gui/gmoccapy.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc_es.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc_es.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc-cn.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc-cn.txt left in tree. Auto-merging docs/man/man9/hostmot2.9 CONFLICT (content): Merge conflict in docs/man/man9/hostmot2.9 Auto-merging docs/man/man9/hm2_eth.9 Auto-merging debian/changelog CONFLICT (content): Merge conflict in debian/changelog Auto-merging VERSION CONFLICT (content): Merge conflict in VERSION warning: inexact rename detection was skipped due to too many files. warning: you may want to set your merge.renamelimit variable to at least 2086 and retry the command. Automatic merge failed; fix conflicts and then commit the result. pins.c, hostmot2.h, hostmot2.c, release_notes.txt, hostmot2.9, hm2_eth.9 changelog and VERSION should all be resolved by --ours. That leaves pncconf private_data.py, pnconf.py builf_HAL.py from pncconf. I think that these, too, are a result of the 7i96s support and need to be solved with --ours. That leaves some docs fixes (which are easy to understand) So, the only one that I don't know how to solve just by looking at the list is cam_align_handler.py. My proposal is to do this as (probably) the last merge of 2.8 to 2.9 and then I think that 2.9 to master going forwards will go more smoothly. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
From: Hans Unzner Sent: November 29, 2022 6:35 PM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy >> >> Then email the folks who know more about the conflict and ask them to >> merge their bugfix into 2.9. >A problem I see here is if the person who introduced this change doesn't >have push permissions to the repository to resolve the merge conflict by >himself. >What is the best solution to resolve it in this case? The only solution, given our current strategy, is to wait/ask for someone else to fix it. This is the crux of the problem. Chris ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
Am 28.11.22 um 02:44 schrieb Sebastian Kuzminsky: I still think merging upwards is the best way to do this. The main advantage is that git keeps track of what commits need to be propagated to the newer branch, so we'll never leave behind any bugfix commits in older stable branches. This avoids the terrible situation where we fix a bug in the stable branch, but the bug is "reintroduced" in the development branch because the bugfix commit never made it in to the newer branch. That said, I *am* sympathetic to the concern that if part of the software has evolved significantly between the stable branch and the development branch, and that part of the software got a bugfix, then the merge may have significant conflicts... So let me be specific, and compare the two situations, so we have a common place to discuss from. # Scenario 1 In this scenario the old stable branch (2.8) has several new commits: some that add a new driver, then a bugfix in old code, then some that add another new driver. The new branch (2.9) has lots of changes, but nothing that conflicts with the new stuff in 2.8. "Merging up" looks like this: $ git checkout 2.9 $ git merge origin/2.8 There are no conflicts so the merge is automatic. "Cherry-pick" looks like this: $ git checkout 2.9 # identify the list of commits needed, and cherry-pick each one Identifying the list of commits needed is a manual, error-prone process. Git doesn't provide much help here - you have to walk backwards through history in 2.8, and for each commit you have to guess if it has been already cherry-picked into 2.9 by searching for it in the 2.9 commit history. The only thing you have to go on is the commit message - if they're the same, then the 2.9 commit was probably cherry-picked from 2.8 (unless it was cherry-picked the other way, or reimplemented independently). Once you find a commit in 2.8 that's already in 2.9, then you may assume that every 2.8 commit *after* that one is new and should be cherry-picked into 2.9. You cherry-pick all the commits starting at that first new one and ending at the tip of 2.8, in order, into 2.9. In the current scenario there are no conflicts, so this process goes smoothly. But even in this easy scenario, this is a lot of error-prone manual labor. # Scenario 2 This is just like Scenario 1, except the bugfix in the old code *does* conflict with changes in 2.9. "Merging up" looks like this: $ git checkout 2.9 $ git merge origin/2.8 The merge detects the conflict and stops halfway through. You have a choice here: if it's a simple conflict you can resolve it yourself and finish the merge, or if it's too complicated you can `git merge --abort` and punt it to someone else. If you choose to punt, you have the option to do just the easy first part of the merge (remember, in this scenario 2.8 has a new driver, then a conflicting bugfix, then another new driver). So you would run `git log origin/2.8 ^origin/2.9` to see the log of just the not-yet-propagated new commits that are in 2.8. You'd identify the commit that finishes the first driver add, and `git merge` that commit into 2.9. (There will be no conflicts, according to this scenario.) Then email the folks who know more about the conflict and ask them to merge their bugfix into 2.9. A problem I see here is if the person who introduced this change doesn't have push permissions to the repository to resolve the merge conflict by himself. What is the best solution to resolve it in this case? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
Strategy is just the agreed upon approach we use in the project. Currently our strategy is to merge up released branches up to master. In practice we almost always just merge up the last last release branch up to master. See my answer to Seb for morexdetails of my reasoning of why I think we could do better using a different strategy, but the jest of it is there is never multiple merge conflicts and the person who knows the code would be doing the cherrypick or commit to the next branch. Chris Original message From: Steffen Möller Date: 2022-11-28 8:54 a.m. (GMT-08:00) To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy > Gesendet: Montag, 28. November 2022 um 06:43 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Can you explain why merging up is better then cherry-picking or separate > commits? @Seb explains this better, my short answer would be that it seems easier. > Merge strategy should not change based on what should or should not be moved > forward. > The strategy must be the same. I may misunderstand the word "strategy". The strategy I think is that every bug is fixed at its root. That strategy is the operationalized with the help of the assumption that if that root existed prior to 2.9 then the fix should also be performed on the branch that represents 2.9 and that if the master branch can pull from 2.9 then the fix gets fixed in the current version, too. Now, I know that this is not always possible. The most trivial counter-example coming to my mind is a typo in the name of a pin. If a correction involves that changed pin name (or another part of an API change) then the mere pull is not sufficient to fix the bug. Extra insights are required. Also, a problem may refer to a function that was removed. But this does not interfere with the basic strategy to fix early and pull. Some un-pull-able change should likely then be in another branch like "2.9-release" that branches off from "2.9". The benefit of merging up over a cherry-pick IMHO is that it looks like more robust. But that is more like a gut feeling than me knowing. If the cherry-patches go into 2.9 and the 2.9-only-fruits go into a 2.9-release branch then I think this looks mostly equivalent? Best, Steffen > > From: Steffen Möller > Sent: November 28, 2022 1:04 AM > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Merge Strategy > > IMHO we should continue with the merge-up and start thinking again when there > is a change to 2.9 that should not be forwarded. > Best, > Steffen > > > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr > > Von: "Chris Morley" > > An: "EMC developers" > > Betreff: Re: [Emc-developers] Merge Strategy > > > > Well we will never agree on anything different if we never discuss it. > > How about throwing out an opinion here? > > > > Chris > > > > From: Hans Unzner > > Sent: November 27, 2022 10:54 AM > > To: emc-developers@lists.sourceforge.net > > > > Subject: Re: [Emc-developers] Merge Strategy > > > > I agree that we should stick to "merge up" until we reach an agreement > > to change this. > > > > Hans > > > > Am 23.11.22 um 22:42 schrieb Chris Morley: > > > Ya it's always been hard to consistently get answers in our project. > > > It just seems the nature of our group. > > > Thanks for continuing to try. > > > > > > Currently strategy is to merge up, though you can cherry-pick up too, as > > > a merge later should understand this. > > > But we rarely do anything with an older-then-current-release (I realize > > > that 2.8 is still sorta current) > > > > > > On the absence of an agreement, I am merging up 2.9 to master to keep in > > > sync. > > > > > > Chris > > > > > > From: andy pugh > > > Sent: November 23, 2022 4:59 PM > > > To: EMC developers > > > Subject: [Emc-developers] Merge Strategy > > > > > > On Tue, 8 Nov 2022 at 21:38, Chris Morley > > > wrote: > > >> I wonder if we might discuss a different merging strategy for 2 9/master. > > >> This would be relative to work being done in 2.9 for release. > > >> > > >> I suggest we don't merge up any more. > > >> Cherry pick or a separate commit makes more sense to me. > > >> > > > Well, the discussion seems to have resulted in nothing happening,
Re: [Emc-developers] Merge Strategy
> Gesendet: Montag, 28. November 2022 um 06:43 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Can you explain why merging up is better then cherry-picking or separate > commits? @Seb explains this better, my short answer would be that it seems easier. > Merge strategy should not change based on what should or should not be moved > forward. > The strategy must be the same. I may misunderstand the word "strategy". The strategy I think is that every bug is fixed at its root. That strategy is the operationalized with the help of the assumption that if that root existed prior to 2.9 then the fix should also be performed on the branch that represents 2.9 and that if the master branch can pull from 2.9 then the fix gets fixed in the current version, too. Now, I know that this is not always possible. The most trivial counter-example coming to my mind is a typo in the name of a pin. If a correction involves that changed pin name (or another part of an API change) then the mere pull is not sufficient to fix the bug. Extra insights are required. Also, a problem may refer to a function that was removed. But this does not interfere with the basic strategy to fix early and pull. Some un-pull-able change should likely then be in another branch like "2.9-release" that branches off from "2.9". The benefit of merging up over a cherry-pick IMHO is that it looks like more robust. But that is more like a gut feeling than me knowing. If the cherry-patches go into 2.9 and the 2.9-only-fruits go into a 2.9-release branch then I think this looks mostly equivalent? Best, Steffen > > From: Steffen Möller > Sent: November 28, 2022 1:04 AM > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Merge Strategy > > IMHO we should continue with the merge-up and start thinking again when there > is a change to 2.9 that should not be forwarded. > Best, > Steffen > > > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr > > Von: "Chris Morley" > > An: "EMC developers" > > Betreff: Re: [Emc-developers] Merge Strategy > > > > Well we will never agree on anything different if we never discuss it. > > How about throwing out an opinion here? > > > > Chris > > > > From: Hans Unzner > > Sent: November 27, 2022 10:54 AM > > To: emc-developers@lists.sourceforge.net > > > > Subject: Re: [Emc-developers] Merge Strategy > > > > I agree that we should stick to "merge up" until we reach an agreement > > to change this. > > > > Hans > > > > Am 23.11.22 um 22:42 schrieb Chris Morley: > > > Ya it's always been hard to consistently get answers in our project. > > > It just seems the nature of our group. > > > Thanks for continuing to try. > > > > > > Currently strategy is to merge up, though you can cherry-pick up too, as > > > a merge later should understand this. > > > But we rarely do anything with an older-then-current-release (I realize > > > that 2.8 is still sorta current) > > > > > > On the absence of an agreement, I am merging up 2.9 to master to keep in > > > sync. > > > > > > Chris > > > > > > From: andy pugh > > > Sent: November 23, 2022 4:59 PM > > > To: EMC developers > > > Subject: [Emc-developers] Merge Strategy > > > > > > On Tue, 8 Nov 2022 at 21:38, Chris Morley > > > wrote: > > >> I wonder if we might discuss a different merging strategy for 2 9/master. > > >> This would be relative to work being done in 2.9 for release. > > >> > > >> I suggest we don't merge up any more. > > >> Cherry pick or a separate commit makes more sense to me. > > >> > > > Well, the discussion seems to have resulted in nothing happening, and > > > some things in 2,8 that probably do belong in 2.9 and master. > > > > > > So what _is_ the current policy? > > > > > > > > > -- > > > atp > > > "A motorcycle is a bicycle with a pandemonium attachment and is > > > designed for the especial use of mechanical geniuses, daredevils and > > > lunatics." > > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > > > > ___ > > > Emc-developers mailing list > > &g
Re: [Emc-developers] Merge Strategy
Can you explain why merging up is better then cherry-picking or separate commits? Merge strategy should not change based on what should or should not be moved forward. The strategy must be the same. Chris From: Steffen Möller Sent: November 28, 2022 1:04 AM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy IMHO we should continue with the merge-up and start thinking again when there is a change to 2.9 that should not be forwarded. Best, Steffen > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Well we will never agree on anything different if we never discuss it. > How about throwing out an opinion here? > > Chris > > From: Hans Unzner > Sent: November 27, 2022 10:54 AM > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Merge Strategy > > I agree that we should stick to "merge up" until we reach an agreement > to change this. > > Hans > > Am 23.11.22 um 22:42 schrieb Chris Morley: > > Ya it's always been hard to consistently get answers in our project. > > It just seems the nature of our group. > > Thanks for continuing to try. > > > > Currently strategy is to merge up, though you can cherry-pick up too, as a > > merge later should understand this. > > But we rarely do anything with an older-then-current-release (I realize > > that 2.8 is still sorta current) > > > > On the absence of an agreement, I am merging up 2.9 to master to keep in > > sync. > > > > Chris > > > > From: andy pugh > > Sent: November 23, 2022 4:59 PM > > To: EMC developers > > Subject: [Emc-developers] Merge Strategy > > > > On Tue, 8 Nov 2022 at 21:38, Chris Morley > > wrote: > >> I wonder if we might discuss a different merging strategy for 2 9/master. > >> This would be relative to work being done in 2.9 for release. > >> > >> I suggest we don't merge up any more. > >> Cherry pick or a separate commit makes more sense to me. > >> > > Well, the discussion seems to have resulted in nothing happening, and > > some things in 2,8 that probably do belong in 2.9 and master. > > > > So what _is_ the current policy? > > > > > > -- > > atp > > "A motorcycle is a bicycle with a pandemonium attachment and is > > designed for the especial use of mechanical geniuses, daredevils and > > lunatics." > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
I still think merging upwards is the best way to do this. The main advantage is that git keeps track of what commits need to be propagated to the newer branch, so we'll never leave behind any bugfix commits in older stable branches. This avoids the terrible situation where we fix a bug in the stable branch, but the bug is "reintroduced" in the development branch because the bugfix commit never made it in to the newer branch. That said, I *am* sympathetic to the concern that if part of the software has evolved significantly between the stable branch and the development branch, and that part of the software got a bugfix, then the merge may have significant conflicts... So let me be specific, and compare the two situations, so we have a common place to discuss from. # Scenario 1 In this scenario the old stable branch (2.8) has several new commits: some that add a new driver, then a bugfix in old code, then some that add another new driver. The new branch (2.9) has lots of changes, but nothing that conflicts with the new stuff in 2.8. "Merging up" looks like this: $ git checkout 2.9 $ git merge origin/2.8 There are no conflicts so the merge is automatic. "Cherry-pick" looks like this: $ git checkout 2.9 # identify the list of commits needed, and cherry-pick each one Identifying the list of commits needed is a manual, error-prone process. Git doesn't provide much help here - you have to walk backwards through history in 2.8, and for each commit you have to guess if it has been already cherry-picked into 2.9 by searching for it in the 2.9 commit history. The only thing you have to go on is the commit message - if they're the same, then the 2.9 commit was probably cherry-picked from 2.8 (unless it was cherry-picked the other way, or reimplemented independently). Once you find a commit in 2.8 that's already in 2.9, then you may assume that every 2.8 commit *after* that one is new and should be cherry-picked into 2.9. You cherry-pick all the commits starting at that first new one and ending at the tip of 2.8, in order, into 2.9. In the current scenario there are no conflicts, so this process goes smoothly. But even in this easy scenario, this is a lot of error-prone manual labor. # Scenario 2 This is just like Scenario 1, except the bugfix in the old code *does* conflict with changes in 2.9. "Merging up" looks like this: $ git checkout 2.9 $ git merge origin/2.8 The merge detects the conflict and stops halfway through. You have a choice here: if it's a simple conflict you can resolve it yourself and finish the merge, or if it's too complicated you can `git merge --abort` and punt it to someone else. If you choose to punt, you have the option to do just the easy first part of the merge (remember, in this scenario 2.8 has a new driver, then a conflicting bugfix, then another new driver). So you would run `git log origin/2.8 ^origin/2.9` to see the log of just the not-yet-propagated new commits that are in 2.8. You'd identify the commit that finishes the first driver add, and `git merge` that commit into 2.9. (There will be no conflicts, according to this scenario.) Then email the folks who know more about the conflict and ask them to merge their bugfix into 2.9. "Cherry-pick" looks like this: Actually it looks just like Scenario 1 (including all the manual searching and guessing), except the cherry-pick of the bugfix will conflict, and at that point you fix it or punt just like in the "merging up" case. So that's my thinking. I hope this shows why i think merging up is better than cherry-picking. -- Sebastian Kuzminsky On 11/27/22 11:11, Chris Morley wrote: Well we will never agree on anything different if we never discuss it. How about throwing out an opinion here? Chris From: Hans Unzner Sent: November 27, 2022 10:54 AM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy I agree that we should stick to "merge up" until we reach an agreement to change this. Hans Am 23.11.22 um 22:42 schrieb Chris Morley: Ya it's always been hard to consistently get answers in our project. It just seems the nature of our group. Thanks for continuing to try. Currently strategy is to merge up, though you can cherry-pick up too, as a merge later should understand this. But we rarely do anything with an older-then-current-release (I realize that 2.8 is still sorta current) On the absence of an agreement, I am merging up 2.9 to master to keep in sync. Chris From: andy pugh Sent: November 23, 2022 4:59 PM To: EMC developers Subject: [Emc-developers] Merge Strategy On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: I wonder if we might discuss a different merging strategy for 2 9/master. This would be relative to work being done in 2.9 for release. I suggest we don'
Re: [Emc-developers] Merge Strategy
IMHO we should continue with the merge-up and start thinking again when there is a change to 2.9 that should not be forwarded. Best, Steffen > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr > Von: "Chris Morley" > An: "EMC developers" > Betreff: Re: [Emc-developers] Merge Strategy > > Well we will never agree on anything different if we never discuss it. > How about throwing out an opinion here? > > Chris > > From: Hans Unzner > Sent: November 27, 2022 10:54 AM > To: emc-developers@lists.sourceforge.net > > Subject: Re: [Emc-developers] Merge Strategy > > I agree that we should stick to "merge up" until we reach an agreement > to change this. > > Hans > > Am 23.11.22 um 22:42 schrieb Chris Morley: > > Ya it's always been hard to consistently get answers in our project. > > It just seems the nature of our group. > > Thanks for continuing to try. > > > > Currently strategy is to merge up, though you can cherry-pick up too, as a > > merge later should understand this. > > But we rarely do anything with an older-then-current-release (I realize > > that 2.8 is still sorta current) > > > > On the absence of an agreement, I am merging up 2.9 to master to keep in > > sync. > > > > Chris > > > > From: andy pugh > > Sent: November 23, 2022 4:59 PM > > To: EMC developers > > Subject: [Emc-developers] Merge Strategy > > > > On Tue, 8 Nov 2022 at 21:38, Chris Morley > > wrote: > >> I wonder if we might discuss a different merging strategy for 2 9/master. > >> This would be relative to work being done in 2.9 for release. > >> > >> I suggest we don't merge up any more. > >> Cherry pick or a separate commit makes more sense to me. > >> > > Well, the discussion seems to have resulted in nothing happening, and > > some things in 2,8 that probably do belong in 2.9 and master. > > > > So what _is_ the current policy? > > > > > > -- > > atp > > "A motorcycle is a bicycle with a pandemonium attachment and is > > designed for the especial use of mechanical geniuses, daredevils and > > lunatics." > > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
Well we will never agree on anything different if we never discuss it. How about throwing out an opinion here? Chris From: Hans Unzner Sent: November 27, 2022 10:54 AM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge Strategy I agree that we should stick to "merge up" until we reach an agreement to change this. Hans Am 23.11.22 um 22:42 schrieb Chris Morley: > Ya it's always been hard to consistently get answers in our project. > It just seems the nature of our group. > Thanks for continuing to try. > > Currently strategy is to merge up, though you can cherry-pick up too, as a > merge later should understand this. > But we rarely do anything with an older-then-current-release (I realize that > 2.8 is still sorta current) > > On the absence of an agreement, I am merging up 2.9 to master to keep in sync. > > Chris > > From: andy pugh > Sent: November 23, 2022 4:59 PM > To: EMC developers > Subject: [Emc-developers] Merge Strategy > > On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: >> I wonder if we might discuss a different merging strategy for 2 9/master. >> This would be relative to work being done in 2.9 for release. >> >> I suggest we don't merge up any more. >> Cherry pick or a separate commit makes more sense to me. >> > Well, the discussion seems to have resulted in nothing happening, and > some things in 2,8 that probably do belong in 2.9 and master. > > So what _is_ the current policy? > > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
I agree that we should stick to "merge up" until we reach an agreement to change this. Hans Am 23.11.22 um 22:42 schrieb Chris Morley: Ya it's always been hard to consistently get answers in our project. It just seems the nature of our group. Thanks for continuing to try. Currently strategy is to merge up, though you can cherry-pick up too, as a merge later should understand this. But we rarely do anything with an older-then-current-release (I realize that 2.8 is still sorta current) On the absence of an agreement, I am merging up 2.9 to master to keep in sync. Chris From: andy pugh Sent: November 23, 2022 4:59 PM To: EMC developers Subject: [Emc-developers] Merge Strategy On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: I wonder if we might discuss a different merging strategy for 2 9/master. This would be relative to work being done in 2.9 for release. I suggest we don't merge up any more. Cherry pick or a separate commit makes more sense to me. Well, the discussion seems to have resulted in nothing happening, and some things in 2,8 that probably do belong in 2.9 and master. So what _is_ the current policy? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Merge Strategy
Ya it's always been hard to consistently get answers in our project. It just seems the nature of our group. Thanks for continuing to try. Currently strategy is to merge up, though you can cherry-pick up too, as a merge later should understand this. But we rarely do anything with an older-then-current-release (I realize that 2.8 is still sorta current) On the absence of an agreement, I am merging up 2.9 to master to keep in sync. Chris From: andy pugh Sent: November 23, 2022 4:59 PM To: EMC developers Subject: [Emc-developers] Merge Strategy On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: > > I wonder if we might discuss a different merging strategy for 2 9/master. > This would be relative to work being done in 2.9 for release. > > I suggest we don't merge up any more. > Cherry pick or a separate commit makes more sense to me. > Well, the discussion seems to have resulted in nothing happening, and some things in 2,8 that probably do belong in 2.9 and master. So what _is_ the current policy? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Merge Strategy
On Tue, 8 Nov 2022 at 21:38, Chris Morley wrote: > > I wonder if we might discuss a different merging strategy for 2 9/master. > This would be relative to work being done in 2.9 for release. > > I suggest we don't merge up any more. > Cherry pick or a separate commit makes more sense to me. > Well, the discussion seems to have resulted in nothing happening, and some things in 2,8 that probably do belong in 2.9 and master. So what _is_ the current policy? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
