FreePascal und Lazarus ziehen um

[Michl]

Servus,

FreePascal und Lazarus werden zu Gitlab umziehen. Genaueres auf Englisch: https://forum.lazarus.freepascal.org/in ... 121.0.html

Der Umzug findet am Wochenende 17./18. Juli statt nach: https://gitlab.com/freepascal.org
FreePascal: https://gitlab.com/freepascal.org/fpc
Lazarus: https://gitlab.com/freepascal.org/lazarus

Aktuell sind dort nur Testversionen vorhanden.

Fehler bzw. Anfragen werden in Zukunft nicht mehr in Mantis, sondern in Gitlab verwaltet. Die Einträge im Bugtracker werden jedoch nicht gelöscht, sondern ziehen mit um. Dies geschieht automatisch mit einer dafür geschriebenen Anwendung. Damit die Einträge richtig zugeordnet werden können, ist es wichtig, daß die Benutzernamen vom Bugtracker denen in Gitlab zugeordnet werden können.

Also wer im Bugtracker aktiv ist, sollte ein Gitlab Benutzerkonto erstellen und zuordnen, um weiterhin seine eigenen Beiträge zu finden. Dazu muss man dann einfach einen Eintrag im Mantis Bugtracker machen:
Project: Mantis
Category: Gitlab
Summary: Benutzername von Gitlab

Der Rest vom Bugreport kann frei bleiben.

Beispiel: https://bugs.freepascal.org/view.php?id=39052

[af0815]

wenn ich mir die Diskusaion ansehe. Naja. Zeigt das GIT und die Umstellung ohne das Schlachten von heiligen Kühen nicht gehen wird.

Für mich stellt sich die Frage: Warum jetzt auf einmal ?

[m.fuchs]

Weil (ihhh)git halt besonders fancy und hip ist, vermutlich.

Ohne Not so etwas zu machen ist in meinen Augen sinnlos.

[hum4n0id3]

Weil (ihhh)git halt besonders fancy und hip ist, vermutlich.

Weil es eher nützlich und zugänglich ist. Also ich begrüße die Umstellung auf Git wirklich. Kann ich schließlich auch etwas damit Anfangen

Und ich nehme stark an dass das die Idee dahinter ist, das mehr Entwickler damit erreicht werden können..

[six1]

Ohne Not so etwas zu machen ist in meinen Augen sinnlos.

Haben wir da verlässliche Zahlen, wie groß die Not ist bzw. war?

[Michl]

Warum jetzt auf einmal ?

Bin zwar hauptsächlich Zaungast, aber die Diskussion gibt es schon sehr sehr lange. Nun wird der Schritt auch gegen diversen Widerstand gegangen. Das Lazarus Dev Team folgt dabei dem FreePascal Dev Team (was da der ausschlaggebende Grund war, weiß ich nicht).

Persönlich stehe ich dem offen gegenüber. Bin selber neu in GIT (habe es bisher nur zum clonen verwendet), aber das eizigste was ich bisher sehe, was ich vermissen werde, sind die Revisionsnummern - habe diese gern genutzt. Zur Zeit finden Überlegungen statt, wie man diese adäquat ersetzen kann (weiß noch nicht so recht, ob dies überhaupt nötig ist, da Datum oder GIT-Hash verwendet werden können).
Bisherige Tests mit TortoiseGIT stimmen mich in der Summe eher optimistisch. Fantastisch finde ich die Umstellung der Branches im ein und dem selben Verzeichnis. Bisher hatte ich für verschiedene Arbeiten verschiedene Clone/Verzeichnisse. Das wird bzw. hat das schon jetzt meine Arbeitsweise verändert und ich verstehe, wenn jemand, der mit GIT zu arbeiten gewohnt ist, das nicht missen möchte.
Als Resümee dieser Tests nehme ich für mich mit, ich komme mit SVN sowie GIT klar. Ob letztlich die Projekte eher davon profitieren oder nicht, das wird wohl erst die Zukunft zeigen.

[af0815]

Was mir eher bedenken bereitet ist, das da versucht wird mittel Tag ein SVN Verhalten zu erzwingen. Die Diskussion zeigt aber, das geistig nicht in GIT gedacht wird und damit der Workflow auf GIT optimiert wird, sondern die bisherigen Ideen auch darauf basieren den SVN nachzubilden. Die Krücke mit Tags möge zwar für den Übergang sinnvoll sein, IMHO nicht aber für eine jahrelange Arbeit mit GIT.

Ich habe vor einigen Jahren auch erfahren, das es wirklich 'THINK GIT' heißen muss (und kämpfe mit GIT immer noch ). Der Unterschied zwischen einer zentralen Verwaltung und einer dezentralen Verwaltung ist riesig und die Workflows auch. Auch in der Diskussion habe ich bisher noch nicht gefunden, welches Workflowmodell genommen werden soll.

Zur Zeit finden Überlegungen statt, wie man diese adäquat ersetzen kann (weiß noch nicht so recht, ob dies überhaupt nötig ist, da Datum oder GIT-Hash verwendet werden können).

Das meinte ich mit think GIT. Es gibt in GIT eigentlich nur eine Wahrheit, die ist der Hash. Datum mit kurzen Hash, ist ähnlich zu sehen, wie die Commit-Nummer bei SVN.

Auch habe ich noch nicht gesehen, ob die Umstellung von anderen Projekten schon einmal untersucht wurden ? Benchmarks habe ich in den ganzen Diskussion nicht gefunden. Ich weis allerdings nicht auf welcher Mailingliste da eventuell was gelaufen ist.

Mal sehen ob es was wird.

[PascalDragon]

Weil (ihhh)git halt besonders fancy und hip ist, vermutlich.

Ohne Not so etwas zu machen ist in meinen Augen sinnlos.

Wie Michl bereits geschrieben hat, war das schon länger geplant. Die Diskussion dazu existiert seit 5 Jahren oder mehr. Ich selbst verwende zum Beispiel schon sehr lange git-svn, wenn ich an FPC arbeite. Die Idee war immer nach einem Release den Wechsel zu vollziehen, doch bisher wurde das immer geschoben (und auch ein paar Punkte waren noch nicht klar wie self hosted vs. hosted, oder dass jetzt eben auch Mantis mit umgezogen wird). Es ergab sich jetzt, dass einer der Server erneuert werden musste und beschlossen wurde in dem Zuge auch auf Git umzuziehen.

Randnotiz: ich bin auch sehr gespannt, ob sich hierdurch tatsächlich mehr Merge Requests ergeben. Ich glaube viele (vor allem die User, die immer wieder auf eine Umstellung zu Git pochen) stellen sich das dann sehr trivial vor, vergessen aber, dass wir dennoch diese Merge Requests genau anschauen werden hinsichtlich Inhalt und Coding Style und jetzt zusätzlich auch Commit History des Requests (keine "Datei XY vergessen" Commits). Wir werden Merge Requests genauso zurückweisen oder liegen lassen (wenn keiner mit dem nötigen Wissen Zeit hat) wie es auch heute mit Patches ist (natürlich kann man auch nach wie vor Patches anbieten statt Merge Requests).

[PascalDragon]

Was mir eher bedenken bereitet ist, das da versucht wird mittel Tag ein SVN Verhalten zu erzwingen. Die Diskussion zeigt aber, das geistig nicht in GIT gedacht wird und damit der Workflow auf GIT optimiert wird, sondern die bisherigen Ideen auch darauf basieren den SVN nachzubilden. Die Krücke mit Tags möge zwar für den Übergang sinnvoll sein, IMHO nicht aber für eine jahrelange Arbeit mit GIT.

Die Tags sind dazu da genaue Releases zu markieren, genau wie in SVN. Wenn ich den Code für FPC 3.2.0 haben möchte, dann hole ich mir den Tag release_3_2_0. Der einzige Unterschied ist, dass in SVN ein Tag auch nur ein Branch ist in den committed werden kann. Da beim Abzweigen eines Releases vom Fixes Branch noch ein paar "house keeping" Sachen zu erledigen gibt, sind im Git zusätzlich noch die Release Branches, bevor dann der tatsächliche Tag erfolgt.

Ich habe vor einigen Jahren auch erfahren, das es wirklich 'THINK GIT' heißen muss (und kämpfe mit GIT immer noch ). Der Unterschied zwischen einer zentralen Verwaltung und einer dezentralen Verwaltung ist riesig und die Workflows auch. Auch in der Diskussion habe ich bisher noch nicht gefunden, welches Workflowmodell genommen werden soll.

Wie werden soweit mit dem bisherigen Modell weiterfahren da wir mit diesem Modell gut fahren. Und das ist das wichtigste.

[m.fuchs]

Weil es eher nützlich und zugänglich ist.

Naja, einziger wirklicher Vorteil von so einem verteilten Repository ist, dass man offline arbeiten kann.
Das hilft dann den Entwicklern aus Deutschland und Nordkorea, aber der Rest der Welt hat vermutlich flächendeckend mindestens 4G.

Und ich nehme stark an dass das die Idee dahinter ist, das mehr Entwickler damit erreicht werden können..

Hm, also wenn es da echt Entwickler gibt, die mit SVN nicht klarkommen und nur dann beitragen wenn es GIT gibt... Da weiß ich nicht ob man den Quellcode dann haben möchte.


Ich sehe jedenfalls dass man eine ganze Menge Arbeit in eine Umstellung steckt, aber gleichzeitig die bestehenden Workflows behalten will. Und ob das Ergebnis einen Vorteil bringt ist eher zweifelhaft.

[martin_frb]

Was mir eher bedenken bereitet ist, das da versucht wird mittel Tag ein SVN Verhalten zu erzwingen. Die Diskussion zeigt aber, das geistig nicht in GIT gedacht wird und damit der Workflow auf GIT optimiert wird, sondern die bisherigen Ideen auch darauf basieren den SVN nachzubilden. Die Krücke mit Tags möge zwar für den Übergang sinnvoll sein, IMHO nicht aber für eine jahrelange Arbeit mit GIT.

Wenn sich das auf "git describe" bezieht, dann ist das eigentlich "git verhalten".

Die Möglichkeit im Lazarus About Dialog, einer selbst gebauten trunk oder fixes Version die Angabe "trunk-2_3-59-gd9603ca06a" statt einfach nur "gd9603ca06a" zu haben ist IMHO gut.
Ebenso, als Antwort auf, welche Version hat jemand....

Alles andere ist git hash, und nur git hash.

[hum4n0id3]

Weil es eher nützlich und zugänglich ist.

Naja, einziger wirklicher Vorteil von so einem verteilten Repository ist, dass man offline arbeiten kann.
Das hilft dann den Entwicklern aus Deutschland und Nordkorea, aber der Rest der Welt hat vermutlich flächendeckend mindestens 4G.

Gegenüber Nordkorea ist Deutschland aber ein offenes Land und statt zu jammern, sollten wir aus der Situation Kapital schlagen. Hier erlebt man schließlich noch echte Abenteuer falls man aus so einem Funkloch lebend raus kommt.

Und ich nehme stark an dass das die Idee dahinter ist, das mehr Entwickler damit erreicht werden können..

Hm, also wenn es da echt Entwickler gibt, die mit SVN nicht klarkommen und nur dann beitragen wenn es GIT gibt... Da weiß ich nicht ob man den Quellcode dann haben möchte.

Ich habe eher SourceForge gemeint.

[Soner]

Warum gitlab und nicht github? Warum auf etwas, was wenige leute benutzen, umziehen?
Habt ihr Verschwörungstheoretiker an Board, die befürchten, dass M$ die Weltherrschaft übernimmt.
Jetzte musste ich ein Gitlab-Konto eröffnen um nur bugs zu melden.

[PascalDragon]

Warum gitlab und nicht github? Warum auf etwas, was wenige leute benutzen, umziehen?
Habt ihr Verschwörungstheoretiker an Board, die befürchten, dass M$ die Weltherrschaft übernimmt.

Mit GitLab können wir falls nötig auch auf eine eigene Instanz umziehen, bei GitHub ist das nicht möglich. Das hat auch nichts mit Verschwörungstheoretiker zu tun, sondern wir haben schlicht aus der Erfahrung gelernt, dass es tatsächlich Regelungen gab und gibt, dass US-Unternehmen Code nicht in bestimmte Länder exportieren dürfen (und Zugriff über eine Webseite dieser Firma gilt dabei als „exportieren”). Das hat vor etwa 10 Jahren SourceForge betroffen (und damit indirekt auch uns, weswegen wir auch weiterhin eigene Spiegelserver für die Releases haben) und kann prinzipiell jederzeit wieder kommen.

Jetzte musste ich ein Gitlab-Konto eröffnen um nur bugs zu melden.

Du musstest zuvor auch ein Mantis-Konto eröffnen nur um Bugs melden zu können.

[hum4n0id3]

Warum gitlab und nicht github? Warum auf etwas, was wenige leute benutzen, umziehen?
Habt ihr Verschwörungstheoretiker an Board, die befürchten, dass M$ die Weltherrschaft übernimmt.
Jetzte musste ich ein Gitlab-Konto eröffnen um nur bugs zu melden.

Ich denke das es kein Problem sein sollte, notfalls sich zu Registrieren wenn es mal notwendig sein sollte. So habe ich mich mal auch bei SourceForge registriert um an XAMPP zu kommen. Was man auch ruhig tun darf ... etwas nicht mögen. SF mag ich zum Beispiel gar nicht.