Menu
▾
▴
Re: [Emc-developers] branch protection turned on
|
From: Luca T. <lu...@ai...> - 2026-09-27 00:00:16
|
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<bod...@gm...> > Date: 2026-09-17 6:17 a.m. (GMT-08:00) > To: EMC developers<emc...@li...> > Subject: Re: [Emc-developers] branch protection turned on > > On Thu, 17 Sept 2026 at 13:44, Luca Toniolo<lu...@ai...> 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 > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers |
