Zentral oder dezentral Code-Hosten (war: Ein Ort für Code)

[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

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20210716/2a4dda46/attachment.sig>