Just posting this here for visibility, this was posted on the Meeting
Agenda on gh by Greg Carl aka snowgoer540, and it is relevant to the
discussion here
you can find the original here
https://github.com/LinuxCNC/linuxcnc/discussions/4566
PS:
Anyone that can make it to the Sunday meeting is welcome to join.
---
snowgoer540 yesterday
With regard to #3 <https://github.com/LinuxCNC/linuxcnc/pull/3>, I
apologize, as I won’t be able to attend the meeting. I know I wasn’t
asked to attend - I found out about it through the developer email chain
on the SourceForge website - but I wanted to at least have some
representation, particularly since it appears that others may be coming
into the discussion with an established agenda.
What most concerns me is not that Chris made a perceived mistake (he did
have plenty of discussion surrounding the changes from what I saw).
Mistakes happen, and I have no objection to discussing how changes to
the project should be reviewed going forward. What concerns me is the
way a long-time contributor to this project has been treated as a result.
There are not many active developers left on this project, and there are
even fewer who have been around long enough to understand the history
and context behind the code. That institutional knowledge has value, and
I don't think it should be dismissed.
I also find the response to Chris' mistake difficult to reconcile with
the history of the project. The person who enabled branch protection and
reverted the changes unilaterally has himself committed a number of very
large changes to the codebase with little or no advance discussion, and
in some cases those changes subsequently sat for a year or more with
significant issues still outstanding. None of those changes went through
a PR.
For some examples, look at the discussion surrounding commits 7ebe7d9
<https://github.com/LinuxCNC/linuxcnc/commit/7ebe7d91fced459729c84a4265556692010379c9>,
9d79c2a
<https://github.com/LinuxCNC/linuxcnc/commit/9d79c2aa23e6e6762dfc32b4ad7c4b7d219e9ea4>,
9a45ed9
<https://github.com/LinuxCNC/linuxcnc/commit/9a45ed94f75f2cef5cef29fd92d859d7ab0662a9>,
and 13b52cb
<https://github.com/LinuxCNC/linuxcnc/commit/13b52cb9377b7e998c4efd29f2616bfa737f2bda>.
The point isn't to dredge up the past, it is to point out that the
standard now apparently being applied to Chris’ commits only seems to
apply since someone didn’t like having their toes stepped on.
I am certainly not opposed to code review. I have opened plenty of PRs
for changes where I wanted another set of eyes. I also have commits
where I discussed the changes with other developers privately before
committing them. I have no problem with review when it is actually
useful and appropriate. Collaboration definitely moves things forward.
What I do object to is changing the rules without discussion and then
treating someone as though they violated an established process when
that process did not previously exist or was not previously enforced.
There is also a long-standing precedent for having a maintainer
responsible for a particular portion of the project. As long as I have
been contributing, GUIs have effectively operated that way. The users
generally do not care whether a particular GUI feature was implemented
through a PR, a direct commit, or some other mechanism. They cared that
the feature worked and that bugs were fixed.
For issues in the main portion of the project, changes were generally
handled through PRs, or by the person responsible for that particular
section of the code. That division of responsibility existed for a
reason: people who maintain a particular part of the project develop an
understanding of its history, architecture, and the consequences of
seemingly small changes.
If the project now wants to move to a different development model, I am
willing to discuss that. But I don't think it is reasonable to silently
change the process, apply it retroactively, selectively, and then use
someone's mistake as justification for the change.
-----
On 9/18/26 2:19 AM, Chris Morley wrote:
My work flow has always to push directly.At one time that was the standard way
to do it.
I have been in this project for 20 odd years.
I have done a few pr for ease of people to look at or test with. I usually push
these direct after but not always.
There has been no formal change to prs only. From memory it was discussed but
never agreed on.
In this case push direct or pr would not of changed what happened. I would have
rebased and force pushed to pr and then merged.
The real problem seems to be it was a surprise that I was going to push my own
case. Which as i state is beem standard forever and noone has complained.
In my mind why wouldn't I ? I'd fixed all issues with the only person who
wanted changes. I said I was read to put this code in. There were mo conflicts.
I still don't know exactly what the problem with the branch is.
Now I would be more direct about my intension to push next time for sure, so
I'll own that.
The reason I did a pr is so other could look at it. Hans and I went through
quite a few changes and compromise. I thought the process worked well.
The issue seems to be conflicts in code in gmoccapy. There are going to be
conflicts if we are working on the same code. I have fixed conflicts many times
in this process. This is the process in a healthy project.
Then you guys 'beat' me up on github, pulled my code and locked everyone out of
pushing with no formal discussion.
I take it from that, that if my code cause your code conflicts that is not
allowed but if your code causes conflicts in mine that's fine.
In 23 years I think I've made 1 big mistake. It happens from time to time other
have too.
Most of my work is in guis, particularly qtdragon .I dont want to have to find
a buddy to push my work every time.
Sent from my Galaxy
Finally please dont think that since most of you do something, that that is now
policy.
If you want to change policy let's discuss and try to agree and certainly no
beat someone up for doing something that you could see was normal for them.
Thanks Chris
-------- Original message --------
From: andy pugh<[email protected]>
Date: 2026-09-17 6:17 a.m. (GMT-08:00)
To: EMC developers<[email protected]>
Subject: Re: [Emc-developers] branch protection turned on
On Thu, 17 Sept 2026 at 13:44, Luca Toniolo<[email protected]> wrote:
I ask because most of my direct pushes have been minor doc fixes and such,
where a PR is mostly clicking through ceremony.
Do you push directly to master? Or via a PR? It's perfectly possible
to create a PR and then merge it yourself for trivial /
uncontroversial changes.
Historically we had our own git server, and those devs that had access
pushed their changes directly. Those that did not have access would
have to email a patch to a core dev to be reviewed and (maybe) merged,
We then moved to GitHub and those same developers retained the ability
to push directly. This made things simpler and more transparent for
contributors without push access.
We haven't previously insisted on PRs, and I quite often push to wlo
without a PR.
I think it's probably better to go via a PR, mainly for consistency,
even if it is self-merged by the developer.
--
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
