[Allegro] Argumente fuer git

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eger, liebe Liste,

>> Hier ist also zunaechst einmal ein "Pull"-Konzept grundlegend
>> gewesen, Pro Repository hat eigentlich nur eine Person Schreibrecht,
> 
> Für Allegro scheinen mir eine Reihe relativ unabhängiger 
> Repositories sinnvoll - z.B. 
> - Kern-Klassenbibliothek
> - avanti
> - acon/a99
> - Parametersatz A
> - Parametersatz N
> 
> Die könnten theoretisch auch unter verschiedenen VCS 
> organisiert werden ... ein einheitliches ist natürlich
> besser.

In der Analogie: Der Linux-Kernel (mit Linus Torvalds und Git)
ist natuerlich nur ein Teil von "Linux"-Systemen, es gibt dann
die Distributionen und die einzelnen Software-Pakete (und
deren Bundles wiederum fuer verschiedene Distributionen, mal
Bestandteil derselben und mal extern bereitgestellt).

Dass SourceForge und andere Git anbieten, hat m.E. damit zu
tun, dass dort dann das "zentrale" Repository fuer ein Projekt
liegt, dasjenige, von dem sich alle Entwickler einen Klon ziehen
(und normalerweise nur "offizielles" enthaelt). Das kann, muss
aber nicht unbedingt das (private) Repository des Maintainers
sein - der kann ja schliesslich auch ab und zu mal wechseln
und der zieht ja auch die ihm zur Kenntnis gebrachten Patches
aus Dritt-Repositories, um sie zu verarbeiten. Jedenfalls kommt
mit dem Konzept eines "offiziellen" Repositories m.E. der Push-Aspekt
in die Angelegenheit.

Klar ist, dass Unterprojekte wie "Parameter zu $A.CFG", "Parameter
zu N.CFG", evtl. aber auch "Order und/oder ALF" nicht naturgegeben
denselben Maintainer haben muessen wie das Hauptprojekt "Quellen
zu 'allegro-C'". Insofern wird man auf Beschreibbarkeit des
Zentralrepositories durch die theoretisch mehreren Maintainer
in Bezug auf "ihren" jeweiligen Teilbaum achten muessen. (Hier
haben wir also wieder das "Kooperationsmodell", diesmal auf
der Ebene der Teil-Maintainer, nicht allgemein fuer alle Entwickler)

Allegro-typisch halte ich die einzelnen Unterprojekte fuer nicht besonders
gut voneinander abgrenzbar (man denke an die "universellen" Parameter-
dateien *. at pt, an denen sich diverse konkrete Parameterprojekte
wiederum bedienen koennten/sollten/muessten), es koennte schnell
eine Situation entstehen, wo urspruenglich einzeln aufgebaute
Repositories fuer Unterprojekte Bezug aufeinander nehmen, so dass sie
wiederum irgendwie miteinander gekoppelt werden muessten. Das wird
dann sehr unuebersichtlich. Daher wuerde ich lieber als Anforderung
an das Zentrale "allegro"-Repository stellen, dass es verteilte
Verantwortlichkeiten fuer Unterprojekte (=Teilbaeume) zulassen muss.
Je kleiner der betroffene Personenkreis, umso eher laesst sich das
auch mit verinnerlichten Spielregeln realisieren, der Bedarf an
Unterstuetzung durch die eingesetzte Software ist da nicht so hoch.
Zu bedenken ist ja auch, dass bei SourceForge etc. die Verwaltungssysteme
nicht isoliert da stehen, sondern in ein Site-weites Identitaets- und
Rechteverwaltungssystem eingebunden sind (Maintainer, Sub-Administratoren
fuer Mailinglisten etc., Entwickler, ...).

Generell sind dort aber auch viele Projekte wie "Addon xy zu z":
Wenn etwas Open Source ist, laesst sich ja recht gut ein separates
Feature noch obendrauf setzen, dass man dann bei entsprechendem Bedarf
in das Hauptprodukt einkompiliert oder sogar separat bereitstellen kann.
Insofern koennte also eine Community hingehen und ein Projekt
NGN (= $N next Generation) hochziehen, das kompatibel zu $N-Parametern
ist, nur wesentlich besser. Das waechst und gedeiht, und das "offizielle"
Unterprojekt $N trocknet aus: das waere doch optimal! Umgekehrt $N
von Anfang an als eigenes Projekt in der Wildnis auszusetzen und zu
hoffen, dass sich schon jemand drum kuemmern wird, hielte ich fuer
verwegen...


viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkxv/KYACgkQYhMlmJ6W47Nc0QQAoPSYYPqgsxNZm+w3xulB5ITm
lsD23QzWEYVVo3jACTGHAekhTPHEP16lmhymmS8PJFEVnHv3TrzPfif7uKvDwe0P
Qz5IauXbboicDGyVrhE0M1e6guE95Fxm6TKiAmlpRiuE6gVRP1Mk+vTT5hsEo87i
XbvcyFOVwdO1hwESJ4Q=
=pZ0y
-----END PGP SIGNATURE-----