Re: [Frunge] Git-Repository

[Martin Roppelt]

Moins!

Dennis Heidsiek schrieb:
> Du legst schließlich ein beachtliches Tempo vor; so haben wir
> inzwischen gleich drei Repositories: Git, SVN und CVS.

Ich bitte dich, das ist doch nur die Sache eines Klicks :)

Ich hätte auch ein zweites git-repo genommen, wenn das möglich gewesen 
wäre :) Vllt. hätten wir auch nach einem zusätzlichen frunge-doc-Projekt 
fragen sollen ;)

> Martin Roppelt schrieb am 18.05.2009 15:52 Uhr:
> > Ich möchte festhalten, dass es keinen Sinn macht, die fertigen otfs
> > in das Repo einzuchecken. Das ist erstens für Quellcode gedacht,
> > und zweitens muss es bei jedem git-commit durchgeführt werden (was
> > auch bei einem hook über fontforge (geht der eigentlich auch unter
> >  Windows?) – zumindest später Zeit braucht).
>
> Na ja, kompilierte »Nightly Builds« (oder wie auch immer man das
> nennen will) haben durchaus Vorteile, da sich ein neuer
> Interessierter Nutzer nicht erst groß einarbeiten muss (Repository
> auschecken / Fontforge oder makefile starten), sondern direkt das
> fertige Endergebnis herunterladen und ausprobieren kann. Ich gebe Dir
> aber vollkommen damit recht, dass dies die Dinge technisch
> verkompliziert und zudem auch keine »saubere« Lösung wäre, weshalb
> ich Dir in diesem Punkt hiermit (trotz leichter Bauchschmerzen)
> zustimme. Fertige kompilierte Versionen der Schriften (und der
> Dokumentation) sollten also nur im »Dokumente« Bereich der Savanne im
> Rahmen eines »richtigen« Releases (Frunge 0.1?) auftauchen. Wobei ich
> persönlich überhaupt nichts dagegen hätte wenn wir uns darauf einigen
> würden, dass bei großen (oder schönen) Änderungen eben schnell eine
> otf-Datei über die Mailingliste huschen würde.

Ne, ich wäre dafür, höchstens einmal pro Tag einen Build in den
Download-Bereich zu stellen.

> > Das Lizenzierungsmodell muss eingehalten werden:
> >
> > Eine README, die besagt, dass alle Dateien unter Copyright, GPL FE
> > und OFL stehen. Diese als COPYING im Wurzelverzeichnis und als
> > README in jedem Glyphenverzeichnis.
>
> Grundsätzlich hast Du da meine volle Zustimmung, aber ich hätte eine
>  technische Frage: Warum können die Lizenzhinweise nicht überall 
> einheitlich »COPYING« (»LICENCE« ist unüblich?) heißen? In einer 
> Readme-Datei erwarte ich eher eine grobe Übersicht, was den überhaupt
> in diesem Verzeichnis zu finden ist.

Können wir schon. Aber so finde ich es auch gut (oder besser :)).

> > Wir sollten uns auch auf eine Richtlinie für Commit-Messages
> > einigen:
> >
> > <s>NEW (oder </s>ADD<s>?)</s> voranstellen für neu eingebrachte 
> > Änderungen, Erweiterungen FIX für Fehlerbehebungen oder Änderungen
>
> Ich würde eher zu ADD tendieren, aber so eine »Präkatigorisierung«
> der Commit-Messages finde ich auch sehr sinnvoll :-). Zudem sei auch
> hier nochmal explizit wiederholt, dass die Lognachrichten
> konsequenterweise auf Englisch erfolgen sollen.

Und im Präsens…

> Können wir aber nochmal eben über das Thema »Branches« sprechen? Ich
> in meiner Git-Naivität hätte jetzt erwartet, dass es in unserem 
> Git-Repository pro Schrift einfach ein .sfddir-Verzeichnis geben
> würde. Dem Log zufolge hast Du stattdessen aber neben dem »master«
> noch einen »textura« Branch erstellt – kannst Du mir das bitte
> nochmal kurz erläutern?

Diesen branch können wir, wenn die Schrift gebrauchsfertig ist, bequem
in den master-branch mergen :). Ich wollte nur nicht, dass da etwas
unfertiges in master rumschlummert.

> Und wo wir gerade beim Thema »Repository-Aufteilung« bin: Derzeitig 
> haben wir drei davon: • Git: Für die Sourcen der Schriften, • SVN:
> Für die Sourcen der Dokumentation, • CVS: Für die Dateien unserer
> Hompage¹.
>
> Für Unstrittig halte ich das CVS-Repo (da dies anscheinend so von der
>  Savanne vorgegeben ist, um die Hompage zu verwalten) und das
> Git-Repo (da dies die von Euch präferierte
> Versionsverwaltungsſoftware ist). Aber brauchen wir wirklich noch ein
> SVN, nur um die Schriften und die Dokumentation in verschiedenen
> Repos zu halten?
>
> Schließlich liegt doch auch die Dokumentation in einem
> Quelltext-Format (.tex) und nicht im kompilierten Format (.pdf) für
> den Endnutzer vor (diese gehört vielmehr zu den otf-Dateien bei den
> Releases unter Dokumente). Deshalb würde ich grundsätzlich dafür
> plädieren, Git- und SVN Repository zu vereinigen, etwa Git/README 
> Git/COPYING GIT/GPL … Git/Font/ Git/Font/Textura Git/Font/Fraktur … 
> Git/doc/ Git/doc/en/manual.tex …
>
> Martin, Arno, sagst mir einfach, wenn ich hier gerade Stuss verzapfe
> ;-).

Also, Stuss ist das nicht. Aber wer braucht schon Dokumentation ;)? Und
siehst du, wie das repo wieder ein Stück unübersichtlicher und
verschachtelter wird?

Ich dachte mir das so: Die Doku gehört ja nicht unbedingt zur fertigen
Software. Wenn ich also dann später ein Paket hätte, dann wäre die Doku
da bestimmt nicht drin… Also muss sie im Quellrepo auch nicht sein.

> Noch eine Kleinigkeit: Was genau spricht dagegen, Textdateien mit der
>  Endung .txt (oder auch .utf8?) zu versehen, um den Dateityp zu 
> verdeutlichen – oder denke ich da gerade zu Windows-artig?

Ne, bitte nicht! (Was soll den sonst drin sein, wenn nicht Text ;))

Ich empfehle dir sowieso, eine GNU/Linux-Parallelinstallation¹ für die
Frunge-Arbeit zu benutzen. So hast du keine Probleme zu pushen und du
erhältst einen ersten Kontakt zu GNU/Linux.

Gruß,
Martin

¹ Z. B. dieses Distrolet hier, das ich dir schon einmal vorgeschlagen
hatte: http://chakra-project.org/download-iso.html :) Das hat einen
grafischen Installer, hat ein KDE mit an Bord (du wirst also nicht mit
der Shell alleinegelassen), ist also für Windowser wie geschaffen :)
Falls du Probleme hast, kannst du uns ja gerne fragen (da Chakra ja auch
nur auf Arch GNU/Linux aufsetzt). Kannst aber auch gerne (K)Ubuntu
(Fedora, …) oder ein *BSD-Derivat benutzen.