Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread Chris Morley
1:23 PM To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] Merge 2.9 to master Am 31.12.23 um 13:29 schrieb andy pugh: > On Sun, 31 Dec 2023 at 12:14, Hans Unzner wrote: > >> You mean via Github by the author of the PR? Not sure if that will work. >> Better t

Re: [Emc-developers] Merge 2.9 to master - Partially completed

2023-12-31 Thread Chris Morley
Looks good to me Andy. Thank you. From: andy pugh Sent: December 31, 2023 11:58 AM To: EMC developers Subject: Re: [Emc-developers] Merge 2.9 to master - Partially completed Chris M: Can you look at linuxcnc/lib/python/qtvcp/qt_pstat.py? Based on commit dates I

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread Greg C
My (perhaps unsolicited) opinion is that the person who merges the PR/commits their own changes should carry it through to the upstream branch(es). That way it's always tidy and there's no questions when the next person goes to merge changes to code they're familiar with. I generally try to do th

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread Hans Unzner
Am 31.12.23 um 13:29 schrieb andy pugh: On Sun, 31 Dec 2023 at 12:14, Hans Unzner wrote: You mean via Github by the author of the PR? Not sure if that will work. Better that the person who merges it keep track of it. That assumes that the person who accepts the merge understands the code a

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread andy pugh
On Sun, 31 Dec 2023 at 12:14, Hans Unzner wrote: > You mean via Github by the author of the PR? Not sure if that will work. > Better that the person who merges it keep track of it. That assumes that the person who accepts the merge understands the code as well as the one creating the code, which

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread Hans Unzner
Am 31.12.23 um 13:01 schrieb andy pugh: On Sun, 31 Dec 2023 at 11:50, Hans Unzner wrote: Is it the job of the person who accepts the PR to merge it upstream? Or a secondary task for the Pull Requestor? I think it would be the best if the person who accepts the PR or the persons who makes

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread andy pugh
On Sun, 31 Dec 2023 at 11:50, Hans Unzner wrote: > > Is it the job of the person who accepts the PR to merge it upstream? > > Or a secondary task for the Pull Requestor? > > > I think it would be the best if the person who accepts the PR or the > persons who makes changes which could cause confli

Re: [Emc-developers] Merge 2.9 to master - Partially completed

2023-12-31 Thread andy pugh
Chris M: Can you look at linuxcnc/lib/python/qtvcp/qt_pstat.py? Based on commit dates I think you probably wanted both sets of changes in? (functions mportDefaultHandler from 2.9 and isUsingDefaultHandler + getQSSPaths from master? HÃ¥vard F. Aasen: Can you take a look at emcrsh.cc lines 573-584 &

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread Hans Unzner
Am 31.12.23 um 12:21 schrieb andy pugh: On Sun, 31 Dec 2023 at 10:58, Hans Unzner wrote: It's been a while since 2.9 was merged to master (almost 3 months). I suppose that's one of the drawbacks of working through pull-requests. Is it the job of the person who accepts the PR to merge it up

Re: [Emc-developers] Merge 2.9 to master

2023-12-31 Thread andy pugh
On Sun, 31 Dec 2023 at 10:58, Hans Unzner wrote: > > It's been a while since 2.9 was merged to master (almost 3 months). I suppose that's one of the drawbacks of working through pull-requests. Is it the job of the person who accepts the PR to merge it upstream? Or a secondary task for the Pull R

[Emc-developers] Merge 2.9 to master

2023-12-31 Thread Hans Unzner
It's been a while since 2.9 was merged to master (almost 3 months). Like expected some merge conflicts popped up. So I would please some of the more experienced users to do that merge. Thanks! ___ Emc-developers mailing list Emc-developers@lists.source