Chris,
Thanks, and good to hear you will put the zmq work up again.
On your question about the merge button: there is an option we do not
have enabled, "Allow rebase merging", which would give you exactly what
you do by hand. Today only merge-commit and squash are enabled, so the
button either adds a merge commit or collapses your series into one.
With rebase merging on, your flow is unchanged: rebase on master as you
do now, force-push to the PR branch, let CI run, then "Rebase and
merge". Same bare commits on master, the only difference being that the
matrix ran first. I can put it on the next meeting agenda, or if Andy is
reading, just turn it on and we see how it goes.
Something you should know before you rebuild the branch: the revert was
not complete. hal_bridge.py is still in the tree and still installed,
the HALBRIDGE handling is still in scripts/linuxcnc.in, python3-zmq is
still in debian/control.top.in, zmq is still live in screen_options.py
and hal_glib.py, and the qtdragon docs still describe the bridge. What
went out is the newest layer: the halui pins and embedded python, the
bridgeui package, the softkey and angular jograte work, and the gmoccapy
and axis wiring. So you are not starting from zero, and the parts most
awkward to redo are still there.
I also owe you a partial apology on timing. The HAL API break went in on
Sunday. The idea and the code are Bertho's; the pushing to get it landed
quickly was mine. It renamed the HAL types tree-wide and touched 28
files under lib/python and src/emc/usr_intf, six of which are files in
your reverted set, including halui.cc, gmoccapy.py, qtdragon_handler.py
and three qtvcp widget files. So your re-land now has to cross a rename
it did not have to cross two weeks ago. The old names still work with
deprecation warnings, so nothing of yours breaks outright, but the
conflicts are real, and the timing is on me. If you hit any of them,
send me the branch and I will do the mechanical part. I reviewed
Bertho's code throughout the break, so by now we probably both dream
about red floats on green reals; it will take me minutes rather than an
evening.
Ping me or post an issue on anything that looks like CI infrastructure
rather than your code and I will chase it rather than have you sit on a
rerun button.
Luca
On 9/29/26 11:28 AM, Chris Morley wrote:
Thank you taking the time to write your thoughts on this issue Luca.
I have often used branches to allow the process work through the code and
complain about problems. I don't need a PR for that to happen, I just need to
push a branch to linuxcnc.
In this case I purposely used a draft PR so others could easily look at, try
and comment on the code. It started more as a discussion with experimental code
and worked up to useable code. I think the code was there being moved forward
slowly for a year. The irony is I was trying to get others to look at the code.
:)
What I am not used to is waiting for someone else to push my code.
I got it to a reasonable utility, no conflicts, all tests passed, worked to
completion with the only one asking for improvements (AFAIK) and wanted to get
it in before master moved again.
Also I prefer the commits to be grouped together, so I usually rebase my
commits on top of the current master, check again for problems, and then
pushing. Merge button doesn't do this. This is the reason I pushed directly.
Now I could have done the same with the merge button by force pushing back to
the PR branch and then merging but that is more work.
If I understand correctly, the difference would be a merge message instead of
just the bare commits?
I also look at PRs that are relevant to me or code I know and will merge them
immediately if that seems fitting.
I will rebuild my zmq code and add a PR and wait for the 'new' process to
evaluate it in good faith.
Thanks Chris
________________________________
From: Luca Toniolo <[email protected]>
Sent: September 28, 2026 4:44 AM
To: [email protected] <[email protected]>
Subject: Re: [Emc-developers] branch protection turned on
Chris,
For what it is worth, I think you are right about the part that matters.
The technical question of whether branch protection is on or off is
small next to how the disagreement was handled. Reverting work from
someone who was reachable and talking, on a misunderstanding rather than
a real breakage, costs the project more than any pushed commit could.
Trust is the one thing here that cannot be restored with a patch, and we
are few enough that losing a long-time contributor over a process
argument would be a far worse outcome than any of the code in question.
Reading Andy, the meeting conclusion was that CI enforcement stays off
and branch protection stays off for now, and that the whole thing needs
more discussion rather than a decision handed down. That seems right to me.
On the workflow itself, an invitation rather than a rule: try putting
your next few changes through a PR and see how it feels from the inside.
Not because your commits need a gatekeeper, but because the PR is where
the CI matrix runs, and that matrix catches things none of us can catch
locally: the RTAI build, the arm package builds, the docs and
translation checks, the sim tests on several distributions. Finding that
on a branch is cheap; finding it on master means someone bisects it later.
I will be honest about the cost too, because I do not want to sell it as
painless. The CI is slow, and a fair share of the red you will see is
not your code: apt mirrors that stall, runner images that change under
us, and a handful of tests that still race under load. That is annoying,
and it is the strongest argument the sceptics have. I would rather we
spend the effort fixing those flakes than arguing about gates, and I am
happy to help chase any that hit you.
What I would like out of this thread is not a rule but a habit: when
something someone pushed looks wrong, ask them first, and give it a day.
Almost every case resolves itself in one message. The cases that do not
are rare enough that we do not need machinery for them.
Luca
On 9/28/2026 10:38 AM, Chris Morley wrote:
I recognise that this would be an unpopular decision in the Sunday meeting
group, so I am grateful for the current reversal, even if eventually we go back
to it.
To me even more important then the branch protection being put on, was the
summary decision to do it and to back out code that actually didn't break
anything already in linuxcnc. Especially since I was in immediate (be it slow -
I was at work) communication.
From memory, we have never backout code that wasn't a big mistake.
This was not a mistake, a miss-understandment surely.
If someone had asked me 'hey this really screwed up some important critical
work I need to get in, could we revert those ?' or 'damn sorry I forgot to
mention there were a couple other serious problems I didn't notice' I might
have had a couple questions but probably would have said sure, with no drama.
But to give me vague (code) complaints, berate me, push to the pr branch then
close it, then revert the direct push and basically say make a new pr. Well you
seemed to have panicked and just fk up my pr branch. Remember I said I would
close it.
We all have to have some trust here. I don't have admin rights. I trust that
those that do, wield them with caution and thoughfulness. In the history of
linuxcnc we have had some major mistakes (master pushed to 2.8) a couple times.
There were calls for removing push rights from people or branch protection etc.
Luckily we had a few people that understood it was an honest mistake and
restricting/controlling people is not a good way to get more people to help or
current people stay with the project. Make a major mistake and have the devs
say ok we can fix it, this is how to make sure it doesn't happen, try not to do
that again, then see how much that person feels like this project values the
people in it!
And you have to trust we are not out there trying to mess things up or don't
care about others work. If you look at the comments in the PR I can't see how
you could say it was anything but maybe a surprising misunderstandment.
Chris
________________________________
From: andy pugh <[email protected]>
Sent: September 27, 2026 9:03 PM
To: EMC developers <[email protected]>
Subject: Re: [Emc-developers] branch protection turned on
The consensus amongst those in the Sunday meeting was that it's a good
idea to have branch protection turned on, but not until everyone has
been persuaded.
To this end the decision was made to turn it off until there is
something approaching consensus on the issue.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
