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" <chrisinnana...@hotmail.com> > An: "EMC developers" <emc-developers@lists.sourceforge.net> > 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 <bodge...@gmail.com> > Sent: November 30, 2022 10:24 AM > To: EMC developers <emc-developers@lists.sourceforge.net> > Subject: Re: [Emc-developers] Merge Strategy > > On Wed, 30 Nov 2022 at 07:38, Chris Morley <chrisinnana...@hotmail.com> > 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 > > _______________________________________________ > 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
