Hallo Alex,
> Ich sehe hier nicht so recht den Praxisbezug. ...
dann komme ich mal mit Gedanken aus meiner Praxis als NUTZER:
Upstream ist schon vor Jahren eingegangen. Es gibt 30 Forks, von denen
Nr. 5, 18 21 aktiv zu sein scheinen. Ich entscheide mich für Nr. 5.
Irgendwann gibt es ein Problem und überraschenderweise ist Fork Nr. 13
aus dem Dornröschenschlaf erwacht und fixt das. Ich schreibe issues mit
dem Fix bei Nr. 5, 18 und 21, aber dort passiert nichts. Ok, gut, also
nutze ich jetzt Nr. 13. Ein Jahr später gibt es wieder ein Problem und
Nr. 13 ist tot. Also suche ich wieder die anderen Forks ab ... usw. Das
funktioniert, weil alle Forks auf github.com sind.
Oder eine mich interessierende Vereinssoftware. Die gibt es upstream,
aber die Vereine forken die in ihre Repos und ergänzen Features. Da
upstream ohnehin nix merged, macht auch niemand PRs. Also frage ich
entweder bei den in Betracht kommenden Vereinen einzeln nach oder muss
den gleichen Kram halt nochmal machen.
> auch einen Pull-Request gegen ein auf einer anderen Plattform
> gehostetes Repo stellen, aber sowas sieht man doch sehr selten.
...
> Bei vielen Fixes wird nicht mal versucht die weiter zu tragen.
Jo. Weils ohne Federation viel zu umständlich ist.
> Oder anders gesagt: wieso sollte jemand einen Fix in ein öffentliches
> Repo tun und dann upstream nicht bescheid sagen?
Weils vergessen wird. Weil das Zeit kostet. Weil upstream sowieso nie
merged. Weil upstream tot ist. Es gibt viele denkbare Gründe.
Auf einer zentralen Plattform findet man den Fix aber trotzdem. Auf dem
ganzen klein-klein nie.
Du gehst wie Bernhard von gut organisierten Strukturen bei großen
Softwareprojekten aus. Das ist aber nur der allerkleinste Teil auf den
git-Plattformen.
Viele Grüße
Ilu
Am 16.07.21 um 14:35 schrieb Alexander Dahl:
Hallo Ilu,
ich will mal ein paar Gedanken aus der Praxis einwerfen.
On Fri, Jul 16, 2021 at 12:26:37PM +0200, Ilu wrote:
ich glaube unsere unterschiedliche Sichtweise kommt aus unserer
unterschiedlichen Interessenlage. Ich habe zuletzt ein Projekt betreut, wo
Student:innen und andere Amateure mit Hilfe von git zusammengearbeitet
haben. Keiner von denen hätte jemals für die Nutzung der Plattform gezahlt,
das wäre auch nicht angemessen gewesen. Und einen Account beantragen mit
Studi-Ausweis - nee. Wir haben letztlich ein privates gitlab benutzt, aber
ideal war das nicht, denn nach dem Ende des Projektes müssen die
Teilnehmer:innen da wieder raus. Wo werden sie hingehen? Zu Github.
Ich zahle meinen Vereinsbeitrag für mein git, zwei Städte weiter zahlen
andere für ihrs usw. - sinnvoll ist es nicht, denn die hängen alle isoliert
in der Gegend und wenn man sehen will, ob ein git den Fix für ein Problem
hat, muss man manuell eine Plattform nach der anderen abklappern. Oder
rumfragen. Idiotisch.
Ich sehe hier nicht so recht den Praxisbezug. Maintainer der
upstream-Projekte, die proaktiv nach Forks und Fixes suchen? Das halte
ich für unrealistisch. Üblicherweise ist upstream in den allermeisten
Fällen schon ausgelastet mit der eigenen Arbeit und dem, was von
externen Contributern an sie herangetragen wird.
Aus Sicht von externen Entwicklern sehe ich ebenfalls den Praxisebezug
nicht so recht. Wenn ich meinen Fix bei upstream unterbringen will,
muss ich mich an deren Vorgaben orientieren. Im Zweifel kann ich ggf.
auch einen Pull-Request gegen ein auf einer anderen Plattform
gehostetes Repo stellen, aber sowas sieht man doch sehr selten.
Wenn ich gitlab/hub.com nutze, dann möchte ich schnell und einfach einen
Überblick über eine Software und alle ihre Forks haben - das geht nur
solange die Forks auf derselben Plattform sind, ansonsten finde ich die
nicht. Praktisch lande ich immer auf github.com, selten auf gitlab.com, und
niemals woanders.
Mich würde hier interessieren, was da die Intention ist? Aus Sicht von
externen Forschern, die nicht aktiv an der Entwicklung einer Software
beteiligt sind? Die Beteiligten selbst kommen ja schon in Kontakt,
selbst bei auf verschiedenen Plattformen gehosteten Git-Repos.
Alle Uni-gitlabs sind Inseln, auf denen Code vor sich hinrottet, den niemals
jemand zu Gesicht bekommt. Das müsste alles zusammen-federiert werden, die
staatliche Plattform dazu und unsere hackspace-gitlabs würden wir auch
dranhängen. Heptapod kann ja mitmachen oder auch nicht.
Code, der da jetzt rumgammelt, wird da auch rumgammeln, wenn die Repos
federiert sind. Selbst bei Github macht sich kein Maintainer die
Arbeit, in allen Forks nach irgendwas zu suchen. Der Anstoß muss von
der anderen Seite kommen.
Oder anders gesagt: wieso sollte jemand einen Fix in ein öffentliches
Repo tun und dann upstream nicht bescheid sagen?
Was es hier eher bräuchte um diesen Effekt des vor sich hinrottenden
Codes anzugehen, wäre auch in der Ausbildung mal zu zeigen, wie die
Zusammenarbeit funktioniert und wie man seinen Code tatsächlich
upstream unterbringt. Da fehlt es eher. Bei vielen Fixes wird nicht
mal versucht die weiter zu tragen.
Grüße
Alex
_______________________________________________
FSFE-de mailing list
[email protected]
https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
behandeln: https://fsfe.org/about/codeofconduct
_______________________________________________
FSFE-de mailing list
[email protected]
https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
behandeln: https://fsfe.org/about/codeofconduct
