Wenn du dich hier beteiligen möchtest [...]
Sorry, bei "normalem Vorgehen" müßte man das nicht machen (sprich: hätten nicht andere zusätzliche Arbeit) - wenn ich versuche, in der GitHub-Oberfläche einen Pull-Request zu erstellen, finde ich "freetz-ng/freetz-ng" nicht (mehr) in der Liste:
Kennst Du die "Platzhalter" wie diesen (Bild nicht ins Board geladen, da die Rechte nicht bei mir liegen)?
https://www.kerber-transporte.de/de/img/service.jpg
Nun, zwischen "flysurfer28/freetz" und "fschl/freetz" könnte Dein Repository stehen ... und zwischen "farebers/freetz" und "fesc2000/freetz" das von "fda77". Ich weiß natürlich, daß Du (obwohl der Account für "fda77" seit 2010 existiert) von Dir behauptest, Du hättest gar keinen Plan, wie GitHub funktioniert. Aber vielleicht findet sich ja jemand, der Dir zeigt, wie man wieder zu einem Repository kommt, das den "normalen Abstammungsregeln" folgt.
Noch hast Du alle Chancen dazu, denn im Moment gibt es noch keine weiteren Forks von "freetz-ng", wie man auch im GitHub sehen kann:
Je mehr Arbeit Du in den derzeitigen "Abkömmling" steckst, um so mehr Aufwand wird es sein, das wieder rückgängig zu machen ... so man das irgendwann mal will. Solange es keinen plausiblen Grund für den aktuellen Stand gibt, sollte man das ja auch dann noch "wollen" können, wenn es sich tatsächlich "um ein Versehen" handelte und eine (unnötige) Aktion aus Unkenntnis möglicher Abläufe/Arbeitsweisen beim Hantieren mit Git bzw. GitHub.
Ich kann logischerweise nicht in die Zukunft sehen und weiß daher nicht, wieviele (potentielle) Benutzer von "freetz" Dir dahingehend folgen, daß sie sich (immerhin "n-mal", während die Korrektur des Kurses für "freetz-ng" nur einmalig erfolgen müßte) die Arbeit machen, ihre eigenen Repositories selbst gegen ein neues "Stamm-Repo" zu reorganisieren.
Wenn sie nur ausreichend viele Änderungen vorgenommen haben (einige der Forks sind ja ohnehin "even with freetz/master"), ist das für die Besitzer ein zusätzlicher Aufwand ... ich habe immer noch keine stichhaltige Begründung dafür gelesen, warum man diese Abstammung nun mit Macht unterbrechen mußte. Der einzige Effekt, den das bringt, ist die Unmöglichkeit, solche Pull-Requests ganz einfach mit dem GitHub-GUI "anzubieten".
Also ganz deutlich: Ich denke nicht im Traum dran. Wenn das wieder so weit "glattgezogen" ist, daß ich tatsächlich (wie gegen jedes andere Repository im GitHub, das ein Fork von "Freetz/freetz" ist - siehe den Stammbaum weiter vorne im Thread) nur ein paar Klicks brauche, um mit dem "freetz-ng"-Repository zusammenzuarbeiten, dann gerne ... aber ich werde die "Abstammung" meines Repos nicht auf "freetz-ng" umstellen (also auch nicht "freetz-ng" anstelle von "freetz" forken, nur um die ganzen "Geschwister" meines derzeitigen Repos dann auch nicht mehr sehen zu können in der oben gezeigten Liste im GitHub) und da ich keinen Weg sehe, im GitHub-GUI einen Pull-Request für "freetz-ng" zu erstellen und Du mir das Geheimnis, wie man das für zwei Repositories parallel machen könnte, ja nicht verraten wolltest oder willst (das ist so in der Gegend um #36 herum nachzulesen), ist es Dir durchaus unbenommen, mein Angebot entsprechend selbst zu übernehmen. Schließlich gilt für dieses Unterverzeichnis meines Repos keine gesonderte Lizenz und damit unterliegt es - wie der Rest ohne gesonderte Angabe - der GPLv2.
Denn das "Anbieten" eines PR aus einem eigenen Branch sollte für einen Autoren eben gerade keinen zusätzlichen Aufwand darstellen und da kann Deine Liste in #42 ja nur schwerlich ernst gemeint sein, wenn der Autor Dein Repo klonen, seines als zusätzliche Remote-Quelle dazupacken und dann selbst mittels "cherry-pick" (was die zusätzliche Arbeit ja nun wieder deutlich ihm aufbürdet) irgendwelche Änderungen in diesen Klon übernehmen soll, bevor er aus diesem heraus dann den PR für Dein Repo erzeugt. Was macht er denn dann, wenn er weiter mit anderen zusammenarbeiten will, die ihrerseits weiterhin mit einem "freetz"-Fork arbeiten (wollen)? Genau dieses "entweder oder" bei der Zusammenarbeit ist das Einzige, was durch das Entfernen der (früher ja vorhandenen) Abstammung erreicht wurde - meinetwegen auch aus "Unkenntnis", aber dann ist das erst recht kein Grund, es nicht wieder rückgängig zu machen.
Ich gehe zwar nicht davon aus (nach einigen vorhergehenden Aussagen), daß Du überhaupt bis hier gelesen haben wirst, aber ich versuche es trotzdem noch einmal: Es gibt "best practices" für die Arbeit mit GitHub. Wer sich ernsthaft damit befassen will, als Maintainer für ein OpenSource-Projekt aufzutreten, der sollte sich auch aus dem Erfahrungsschatz anderer bedienen und zum Beispiel einfach mal bei GitHub etwas lesen:
https://opensource.guide/ - das muß zwar nicht gleich in einen "Code of Conduct" ausarten, aber ein paar Regeln sollte man schon aufstellen (und sich dann auch selbst daran halten) und man sollte sich auch von Beginn an überlegen, wie man sein Projekt so gestaltet, daß den potentiellen Mitstreitern die "collaboration" erleichtert und nicht (zumindest nicht ohne echte Notwendigkeit) erschwert wird.
Wenn jemand etwas in seinem eigenen Fork (egal, ob der von "freetz-ng" oder "freetz" abgeleitet wäre, solange beide in demselben Stammbaum liegen) für einen anderen Fork freigeben will, dann macht er das aus seinem einen(!) persönlichen Fork heraus und dieser basiert entweder auf "freetz" oder auf "freetz-ng" - es ist überhaupt kein Problem, einen "cross-fork"-PR zu erstellen (habe ich weiter vorne schon gezeigt). Es gibt also gar keinen einleuchtenden Grund, warum jemand beide Repos in seinem GitHub-Account forken will und damit fällt die "Begründung" für die Notwendigkeit dieses "Abtrennens" aus #42 schlicht unter "Wen interessiert's?".
Jedenfalls, wenn jemand ein Option dazuhaben will, einfach schreiben wie die heissen soll
