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