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

[Ilu]

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
> FSFE-de at lists.fsfe.org
> 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