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@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