Navigation


Suche



Nichts gefunden?
Suche mit erweiterten Optionen.

Anzeigen



Werbung

Kfz Ersatzteile
CMS Software Preise
Datenrettung
Backlink-Checker
SEO Beratung

Das NOC wird renoviert

Freitag, 09. Mai 2008, 5 Kommentare

geschrieben von
Steering Committee : Zur Zeit arbeitet Chris Hildebrandt an einem Nachfolger für die GForge-Installation, die uns in den letzten Jahren als "NOC" (Network Operations Centre) bekannt ist. Der Prototyp ist jetzt so weit forgeschritten, dass ihr mit Euren Projekten umziehen könnt: http://code.zikula.org
So richtig konnte das NOC nie punkten. Obwohl Postnuke als eines der ersten OpenSource Projekte eine zentrale Entwicklungsplattform für die Community einrichtet gab es von anfang an Schwierigkeiten - Login-Probleme, immer wieder Schwächen in der Performance und zuletzt die komplettausfälle durch Spam-Atrtacken. Dagegen kann man keine Server vorhalten. Dazu kam, dass jedes Update zur Qual wurde. GForge ist offenbar nicht für eine einfache Pflege durch Leute gedacht, die sich nur gelegentlich damit befassen. Ich selbst habe meine Erfahrungen mit dem "Templating" gemacht. Aber da bin ich wohl auch von Postnuke verwöhnt...

Nun hat Drak einen neuen Server zur Verfügung gestellt, auf dem Chris Hildebrandt (wmaster) eine Multi-Projektinstallation des Python-Projekttools "Trac" aufsetzt. Trac wird von einer Reihe anderer Open-Source Projekte eingesetzt (z.B. xinha) und ist in dier Basis-Installation wesentlich schlanker als GForge. Während ich mir bei der Konfiguration eines neuen Projektes in GForge immer einen abgebrochen und ich schon eine halbe Stunde mit dem Abschalten aller möglicher Features verbracht habe, ist bei Trac - ohne Erfahrung - ein neues Projekt in 5 Minuten komplett eingerichtet.

Übersicht
Wie im NOC ist wohl das Wichtigste für jeden Modul-Entwickler das Subversion als sicheren Platz für die eigene Arbeit. Ein Trac Projekt (Beispiel)besteht darüber hinaus aus einem Wiki, das gleichzeitig die Startseite ist, einer "Timeline" in der man alle Änderungen am Projekt nachvollziehen kann, einer Roadmap, einem Tracker für Features, Tasks, Bugs usw., der hier "Tickets" heisst und einem Browser für das SVN.

Entwickler
Ihr könnt jetzt mit Euren Projekten umziehen. Einfach eine PN an wmaster mit den Namen Eurer Projekte im NOC und Eurem Usernamen im Trac. Außerdem könnt ihr die Chance nutzen und Eurem Projekt einen neuen Namen geben - denkt dran, dass PN* demnächst nicht mehr nötig sein wird.

Ich richte dann immer erst einmal die Komponenten im Backend ein:
1. Login im Projekt
2. Administration
3. Rechte im Subversion setzen. (Subversion > Permissions) Standardmäßig ist da slam (=wmaster) eingerichtet. Den Namen könnt ihr einfach durch Euren Usernamen ersetzen und in der gleichen Art und Weise weitere User eintragen, wenn ihr mit mehreren Entwicklern an einem Projekt arbeitet.
4. Ticket-System einrichten. Wie im GForge sind hier viel zu viele Felder eingerichtet für Komponenten usw. Wenn man da alle Einträge löscht, werden die im Formular nicht mehr angezeigt.
5. Downloads einrichten. Ich stell auch hier die Dropdowns um: Architeture benutze ich für die Mindestanforderung an die PHP Version (PHP4, PHP5) und Platforms für Postnuke .7 oder Postnuke .8 - Das sieht dann so aus: gravatar Projekt
[Update]: Ihr müsst jetzt noch "anonymous" view Permissions für die Downloads geben. Da könnt ihr zum Beispiel auch die Rechte für die timeline und die Roadmap löschen, wenn ihr die nicht nutzen wollt.
6. Wiki Startseite. Die Startseite sollte einen Überblick übers Projekt geben. Ich hab mir da einmal eine Seite angelegt, die ich jetzt auf alle andere Projekte übernehme (copy&paste). Wenn Euch die Startseite von Locations gefällt, könnt ihr die gerne übernehmen.

Auf der Startseite des Wikis könnt ihr auch die Tags eintragen, unter denen Eurer Projekt gefunden werden soll. Dazu gibt es unter dem Editor-Feld noch ein Tags-Feld.

Das Wiki eignet sich auch hervorragen für eine flexible Dokumentation für Eure Module. Das könnt ihr dann auch direkt aus Euren Modulen verlinken und so immer aktuell halten.
7. Ändert die Projektinfo auf noc.postnuke.com mit dem Hinweis auf den Umzug ins Trac.

Benutzer
Registriert Euch auf http://code.zikula.org und nutzt die Tracker dort für die Module, die schon dorthin übergesiedelt sind.

Perspektive
Es wird ein Single-Sign On mit community.postnuke.com geben, so dass ihr den gleichen User auf beiden Systemen nutzen könnt.

Mateo und ich passen zur Zeit das Layout an das von community.zikula.org und Chris richtet die zentralen Funktionen ein: Die Startseite des Trac sowie die Projektübersicht.

Nach und nach werden jetzt alle Projekte umziehen. Dann macht Drak ein Backup des NOCs und schaltet es ab.

Axel entwickelt darüberhinaus die Extensions Datenbank, in der dann alle Releases zusätzlich auffindbar sind.

Wir hoffen, dass Euch das neue System gefällt und dass wir diesmal mehr Glück mit dem neuen NOC haben. Außerdem würden wir uns über Fragen, Kritik und Anregungen zu diesem Thema freuen.
Mister Wong iconTechnorati iconDigg icondel.icio.us iconma.gnolia iconFurl iconNewsvine iconReddit iconYahoo MyWeb iconBlinkbits iconGoogle iconSimpy iconBlogmarks icon

Kommentare

Nur angemeldete Benutzer dürfen Kommentare verfassen.

Zur Registrierung/Anmeldung

Super HowTo aus der Sicht eines Projektadmin - danke Steffen, genau das hat gefehlt!

Hier noch einige kleine Ergänzungen:

Vor dem Umzug von NOC nach Trac solltet Ihr Eure Projekte wirklich kritisch ausmisten.

Also, erstmal im SVN aufräumen (am besten auf den quasi-Standard der Grundstruktur branches/tags/trunk umbauen - gerne helfe ich dabei auch). In /tags hebt man am besten fertige Releases und veröffentlichte Milestones/Betas/RCs auf. Dort kann man auch - so wie das Core Team das macht - eine veröffentlichte RC bis zur Stable Release noch mit Bigfixes versorgen, während bereits die nächste Version im /trunk gekocht wird. In /branches bearbeitet man parallele Zweige der Entwicklung um Varianten zu testen. Die kann man auch getrost wieder löschen wenn man sie nicht mehr braucht.

Die bereits releasten Pakete in den NOC Dwnloads solltet Ihr sichern, soweit sie noch Sinn machen. Uraltversionen sollten verschwinden.

Der Bugtracker sollte ebenfalls nur mehr das enthalten, was tatsächlich noch relevant ist. Dubiose offene Bugs von vor 5 Jahren, die mit neueren Versionen eurer Module längst überholt sind, kann man getrost mit dem Hinweis "aged" schliessen.

Eventuelle neue Projektnamen sollten gut überlegt sein, einerseits nicht mehr an PN- oder PostNuke erinnern, andererseits klar und einfach am besten erahnen lassen, was das Modul tut. Um nicht mit anderen Modulen oder geschützen Markennamen in Konflikt zu geraten, sollte man ein wenig die Phantasie spielen lassen. Auch Lehnwörter aus anderen Sprachen eignen sich gut, ebenso wie die Griechsiche und Römische Götter- und Heldenwelt. Das gibt Eurer Arbeit dann auch gleich einen akademischen Anstrich. icon_wink

Wenn wir übersiedeln, überlegt gut ob Ihr wirklich die gesamte SVN-Historie mitnehmen wollt, oder nicht lieber gleich mit einer frischen Revision #1 beginnt. Das gleiche gilt für den Bugtracker, besonders geschlossene alte Bugs sind heute wertlos.

Nehmt Euch Zeit mit Trac vertraut zu werden, seht Euch Steffens Projekt (oder andere) als Muster an. Überlegt Euch einen guten Starttext. Denkt über Rechteverteilung in Trac und SVN nach, es gibt da sehr viele feine Möglichkeiten der Differenzierung. Trac kann sehr gut auf die speziellen Bedürfnisse Eures Projektes angepasst werden, es gibt auch eine Vielzahl von optionalen Plugins, die ich Euch auf Wunsch gerne installiere (soweit technisch vertretbar).

Wenn die Übersiedlung (je nach Projektgrösse machen wir das flott gemeinsam in 10 - 30 Minuten) erledigt ist, sollte im alten NOC das SVN und der Bugtracker geschlossen werden.

Gerne stehe ich auch - bevorzugt über IRC auf irc.oftc.net, Kanal #PN supportend zur Verfügung. Im Deutschen und Englischen PN Entwicklerchat bin ich auch meist zu finden.

Ich hoffe dass uns Trac helfen wird $newname noch professioneller zu entwicklen als bisher.

Greetings,

Chris

wmaster am 09.05.2008 um 13:02 Uhr

die Verknüpfung mit der extension Datenbank klingt gut auch die Wikipage wo evtl. die Doku hinterlegt sein kann! Mir fehlt noch die direkte Anbindung zu den Modulen die den Admin anmeckern das es neue Versionen gibt aber hört sich schonmal alles spitze an!

Danke für den Aufwand!

hardtoneselector am 09.05.2008 um 16:07 Uhr

Die Anbindung für den Admin kommt später im Modules-Modul.

Dieses wird auf die neue Extension DB zugreifen und weiß somit, was es an Updates gibt.

Guite am 09.05.2008 um 17:01 Uhr

copy&paste ...

... Deines Startwikis ist als Vorlage nur mit Barbeitungsrecht (Edit this page) möglich. Nu muß ich mir meine eigene Startseite basteln icon_wink

mike12 am 12.05.2008 um 14:14 Uhr

Chris übernimmt das jetzt direkt bei neuen Projekten icon_wink

kaffeeringe.de am 12.05.2008 um 20:19 Uhr