> Gesendet: Sonntag, 08. Januar 2023 um 03:34 Uhr
> Von: "Jeff Epler" <jep...@unpythonic.net>
> An: "EMC developers" <emc-developers@lists.sourceforge.net>
> Betreff: 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.
+1
> 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:
All the changes to the documentation that is not describing new functionality
should have gone to 2.9, so we improve the upcoming release to the best of our
abilities.
Any loss of that work likely stops the influx of improvements to 2.9.
> 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.
This sounds very reasonable. What does that do to future changes to the 2.9
documentation? Anyway - four files sounds much like a non-issue.
> 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".
I think I prefer "devel". Also since this encourages the submission to 2.9.
> 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.
PRs imho are very much a means of communication that I would miss if we would
not have them.
Thank you, Jeff!
Steffen
> _______________________________________________
> 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
