AFAICT the code (I didn't look at the docs mind you) is fixed. What is actually broken in master now? What are we trying to fix? The history?
Why would we change to 'main' ? How does the name change fix merge problems? It does create doc and web reference problems. I disagree with having to use pull requests for devs. (if I understood that right) We already have problems getting pull request reviewed and aproved. These things seem like radical responses to an uncomon mistake. This will be only be the second time in about 15 years something like this happened. If you want to talk merge strategies see my other maillist talk. The jest of is - why merge released branches into master at all. Thanks Chris ________________________________ From: Jeff Epler <jep...@unpythonic.net> Sent: January 8, 2023 2:34 AM To: EMC developers <emc-developers@lists.sourceforge.net> Subject: Re: [Emc-developers] Broken master 06jan23 Thanks for speaking up about the problem as soon as you realized it. I have temporarily locked the "master" branch on github until this problem is resolved. I understand that the idea of force-pushing master to 1d836df^ before the problem was discussed and dismissed (on IRC?). I did not see this discussion. Seb and I have each prepared PRs that approach fixing the problem. I have a third, non-pull-request suggestion. https://github.com/LinuxCNC/linuxcnc/pull/2250 -- Seb re-cherry-picks work from 2.9, excluding doc work that did not apply cleanly. This would mean the doc work is lost from master if nobody else steps up to cherry-pick and pull request the changes to master too: https://github.com/LinuxCNC/linuxcnc/pull/2251 -- I merge 2.9 into 1d836df^ (git notation for "the commit before 1d836df), doing my best to take the better side of each conflict in the documentation (usually it was pretty clear; a total of 4 files had conflicts), then merge 1d836df with the "ours" strategy (to effectively discard its version of the changes), and then cherry-pick commits subsequent to 1d836df, only one of which introduced changes. This hopefully catches the majority of doc work, but I merely selected one side or the other of the doc changes, rather than carefully merging them word by word. The third suggestion is to use this as the moment to adopt the github standard "main" branch name, instead of the deprecated branch name "master". I would prepare a new branch similar to #2251, but NOT merge 1d836df in it, and push this as "main". Besides fixing things in one of these ways, I think we should strongly consider using github "branch protection", so that any change to main and a "branch that looks like a version number" must go through the pull request process. This doesn't catch all problems, and it would require folks to step up as pull request reviewers, but it might have avoided this problem. I'll check back on this thread as well as the developers IRC channel to see if a consensus develops and then implement it. Because this is blocking ongoing work it's problably better to resolve it in a timely fashion than to spend a long time figuring out the best possible resolution. It sounds like Seb is not available for the rest of the week-end fwiw. Jeff _______________________________________________ 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
