[Metalab] Subversion Server neu, Entwicklung allgemein, MetalabOS

[Daniel Bachler]

Hiho,

Ich (http://metalab.at/wiki/Benutzer:DanyX) bin gestern mit enki, Metaz, c3o
und ein paar anderen, mir nicht so vertrauten Gesichert bzgl MetalabOS
zusammengesessen. Nachdem wir gestern eine kurze Einführung von enki in den
bisherigen Source bekommen haben und gemeinsam die wichtigsten Systemteile
für die nähere Zukunft identifiziert haben, geht es jetzt darum eine
ordentliche Entwicklungs-infrastruktur zu schaffen damit wir gemeinsam
loslegen/weitermachen können.

Womit ich beim eigentlichen Punkt dieser E-mail bin (und der rechtfertigung
warum das nicht an MOS at lists.metalab.at geht):

Das Subversion repository liegt derzeit auf einem Privatserver und soll auf
ma.metalab.at migriert werden. Das Repository besteht, soweit ich das bis
jetzt überblicke, aus 2 aktiv genutzen Teilen:

Office, in das Metaz und Graf ihre Prüfungsberichte und
Mitgliedsbeitragszahlungen einchecken, und Projekte, in dem enki seine
bisherigen Ansätze verstreut hat. Von diesen ist nur ein Projekt noch aktiv,
das den Namen decidr trägt und in Wirklichkeit der derzeitige Stand des
MetalabOS projekt ist.

Frage 1: sollen wir das Subversion Repository auf Madame migrieren oder ein
neues Anlegen und die bestehenden Daten dort neu einchecken (und damit die
history verlieren aber uns einige moves/deletes sparen).

Frage 2: Hat sich der office zweig bis jetzt bewährt? Soll office für jeden
Entwickler lesbar sein?

Unabhängig davon würde ich im Projekte Zweig die Best-Practice Nomenklatur
von trunk, branches, tags übernehmen und ab jetzt (denn jetzt sind mehrere
Benutzer beteiligt) eine Policy überlegen nach der trunk immer stable sein
muss, neue Features sollten in Branches entwickelt werden.

Wie siehts überhaupt mit Entwicklungsrichtlinien aus? Ich meine, man muss ja
nicht gleich zwingend festlegen ob nach einem arithmetischen Operator ein
Space kommt oder nicht, aber ist es angedacht ein paar Grundregeln
aufzustellen? Oder jeder wie er will?

Zur gestern bereits angesprochenen Problematik der Konfigfiles, Datenbanken:
Ich wäre dafür, dass die im Subversion eingecheckten Konfigfiles für eine
lokale Testkonfig vorkonfiguriert sind und nicht den echten Namen tragen
(z.b. settings.py.template statt settings.py), der User muss dann nach einem
checkout das template in die entsprechende Konfigdatei kopieren und
anpassen. Um Testdatenbanken zu befüllen war gestern der Konsens, dass
populate-scripts im Subversion vorhanden sein sollten um nach einem checkout
gleich loslegen zu können und nicht erst lauter objekte anlegen zu müssen.

Noch was fällt mir zur entwicklung ein: Inwiefern soll das Wiki des Trac
genützt werden (derzeit wird es überhaupt nicht verwendet)? Mir erscheint es
sinnvoll, das Mediawiki von weiteren Designüberlegungen zu MetalabOS und
anderen Projekten freizuhalten, also mein Vorschlag wäre alles bis auf eine
Übersicht, die im Mediawiki sein kann, im trac zu dokumentieren. 

Opinions? Ideas? Objections?

Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://lists.metalab.at/pipermail/metalab/attachments/20060715/b5dabece/attachment.sig>