Weitere Entwicklung von VirtualFluids (develop and open_source)

Liebe alle,

ich möchte gerne eine Diskussion bezgl. der weiteren Entwicklung von unseren Entwicklungszweigen develop und open source anregen und möchte euch um eure Meinungen bitten.

Aktuelle Situation

Unser Hauptrepository (https://git.rz.tu-bs.de/irmb/VirtualFluids_dev) ist intern zugänglich und besteht aus zwei Zweigen: develop und open_source. Der Branch "open_source" wird gespiegelt in das öffentliche Repository: https://git.rz.tu-bs.de/irmb/VirtualFluids

Die EntwicklerInnen arbeiten in "Forks", privaten Kopien und stellen Merge-Requests um ihre Änderungen in das Hauptrepository zurückzugeben. Diese Änderungen betreffen im wesentlichen nur den Branch "develop". Once in a while werden auch Änderungen in den Branch "open_source" zurück geführt.

Das Problem

Alle Arbeiten finden im Wesentlichen im Branch "develop" statt. Develop divergiert von "open_source", bzw. ist im Fall von VirtualFluids_GPU sogar in Weiten Teilen neu entwickelt wurden. Das führt dazu dass Änderungen/Erweiterungen gar nicht oder oder nur so schwer in Open-Source überführt werden können (z.B. die Weiterentwicklung von Uppsala, die Phytonschnittstellen ect.). Diese Problem nimmt mit der Zeit immer weiter zu.

Lösungsvorschlag

Meines Erachtens gibt es nur eine Lösung: Aus den zwei Entwicklungszweigen muss einer werden, develop muss zu open_source werden, bzw. open_source wird gelöscht. Das würde dann als Konsequenz bedeuten, dass ein Merge-Request einer EntwicklerIn immer direkt in den einen Hauptzweig führen wird (Das Arbeiten mit Forks bleibt erhalten). Warum ist das die einzige Lösung? Die Arbeit mit zwei Zweigen kann funktionieren, aber nur wenn die jeweiligen Änderungen klein sind und oft gemergt wird. Dadurch wird verhindert, dass die Zweige divergieren. Dies halte ich allerdings für unseren Anwendungsfall für unrealistisch.

Die Konsequenz

Änderungen die nur open_source betrafen müssten in develop überführt werden and thats It!

Fazit

Aktuell denke ich, dass dies die einzige langfristig nachhaltige Lösung für VirtualFluids und dessen zukünftige Weiterentwicklung ist. Ich bin sehr gespannt auf eure Meinungen dazu.

@k.kutscher @m.schoenherr @a.wellmann @h.alihussein @s.marcus

changed the description

Ich bin grundsätzlich dafür. Die Frage ist, was man mit neuen Sachen macht, die noch nicht veröfentlich, aber schon drin sind.

Da VirtualFluids Teil des SURESOFT-Projekts ist, sollte ja die Bestrebung sein, Software wie reguläre Publikationen zu behandeln. Wenn also ein Feature in VirtualFluids implementiert wird, das auf einer neuen wissenschaftlichen Erkenntnis basiert, wäre daher meiner Meinung nach das beste Vorgehen, eine Software-Veröffentlichung (bzw. Release) auf dem Publikationsserver der TU hochzuladen und eine DOI zuzuweisen. Natürlich werden dabei alle Beteiligten als Autoren genannt. Falls das zugehörige Paper erst später veröffentlicht wird, kann dort auch die entsprechende VirtualFluids Version zitiert werden.

Werden neue "Features" auf dem Develop Branch entwickelt, oder auf einzelnen Feature-Branches? In diesem Fall sollte es doch unkritisch sein. Es gäbe noch die alternative den open-source Branch jeweils auf eine nicht ganz aktuelle Version des Develop-Branches zu Rebasen. Immer auf die aktuelle "stable/release" Version beispielsweise. Diese kann dann auch über den Publikationsserver veröffentlicht werden und zitierter gemacht werden. Der OS-Branch wäre somit entsprechend dem Main-Branch.

Generell bin ich dafür, dass wir keine separate Open-Source Variante bauen, die im Grunde eine eigenständige Version ist. Die Gründe dafür hat Sören bereits genannt.

Wir haben jetzt VirtualFluids OpenSource archiviert: https://git.rz.tu-bs.de/irmb/archive/virtualfluids/

und virtualfluids_dev heißt jetzt virtualfluids und liegt hier: https://git.rz.tu-bs.de/irmb/VirtualFluids/

und wurde mit version 0.1.0 erstmals veröffentlicht: https://zenodo.org/doi/10.5281/zenodo.10283048

closed