WARNUNG: Der folgende Text liest sich plötzlich wie Werbung für Bitbucket. Das ist allein meiner persönlichen Präferenz geschuldet.
Folgende Entwicklung fände ich sehr begrüßenswert: 1. Migration des Quelltexts (next_release Branch) zu git Wir haben uns lange genug mit Subversion rumgeärgert. Git zu kennen/können ist für alle Informatiker ein Pluspunkt. Das können wir auch von unseren Studenten fordern. Und verteilte Versionsverwaltung rockt einfach. 2. git Hosting auf Social Coding Platform Gibt eine erhöhte Sichtbarkeit, verringerten Wartungsaufwand und bessere Vernetzung mit externen Entwicklern. Mein Favorit wäre hier Bitbucket [1]. Als Akademiker/Open Source Projekt hat man da auch Sonderkonditionen (die wir gar nicht brauchen). Außerdem gibt es eine Menge fertiger Integrationsmöglichkeiten mit anderen Tools (z.B. Jenkins, siehe unten). Mit github könnte ich mich vielleicht auch anfreunden. 3. Collaborative Code Review Alle wissen, dass der Hauptzweig sehr schnell verdreckt, wenn zu viele ungeübte Leute Commit-Rechte haben. Sinnvolle Änderungen müssen über gut dokumentierte Patches (Pull-Requests) eingepflegt werden. Ein modernes Tool, dass sich dafür anbietet und von vielen Projekten genutzt wird, ist Gerrit [2]. Alternativ hat Bitbucket ein eigenes Code Review Interface. Das würde für unsere Zwecke vermutlich auch völlig reichen. 4. Continuous Integration Wir brauchen automatisierte Builds für verschiedene Plattformen, damit wir endlich mitbekommen, wenn mal wieder etwas nicht funktioniert. Eine Instanz von Jenkins [3] wäre hier vermutlich das sinnvollste. Auch wenn mir persönlich das Python-basierte BuildBot besser gefallen würde. Wir müssen unseren Verwaltungsaufwand gering halten, was mit Jenkins vermutlich besser klappt. Jenkins lässt sich gut mit Bitbucket integrieren ;-) (Einbindung direkt in die Website) - das gibt auch interessierten Leuten eine gute Vorstellung vom aktuellen Pflegezustand ihrer Plattform. 5. Dokumentation HowTos und WhitePaper sind zwar eine schöne Sache, aber die einzig aktuelle Dokumentation ist leider auch bei uns nur "der Code". Ich bin dafür, alle Dokumentation auch gleich hier mit unterzubringen, und zwar mittels Doxygen [4]. Das wird bereits gemacht, aber nur halbherzig. Man kann mit Doxygen auch Dokumentation der Konzepte etc. vornehmen. Es muss dort nicht alles an konkreten Klassen/Methoden kleben. Die Dokumentation im HTML-Format sollte dann auch immer irgendwo gehostet sein. Alternativ kann man ein Wiki pflegen, ähnlich unserem aktuellen Trac. Ich will's ja nicht schon wieder erwähnen, aber Bitbucket bietet automatisch zu jedem Repository ein zweites Repository, in dem man das integrierte Wiki verwalten kann (mit reStructuredText, Markdown, Textile, etc.). Eigentlich eine sehr schöne Sache. 6. Issue Tracker Für unsere recht rudimentären Anforderungen reicht uns vermutlich der eingebaute Issue-Tracker von Bitbucket. Wichtig ist, dass er aktiv genutzt wird. Eine Einbindung komplexerer Tools (bspw. das komerzielle JIRA [5]) ist auch möglich. Ich halte das aber nicht für erforderlich. Fazit: Ich denke wenn wir das richtig anstellen, können wir das gesamte Reflex zu Bitbucket umziehen, und müssen "nur noch" das Jenkins irgendwo aufsetzen. Durch verteilte Versionsverwaltung verlieren wir auch bei einem Totalausfall von Bitbucket nicht unseren Code bzw. Dokumentation (Wiki). Das würde unseren Aufwand sehr gering halten und wir sind repräsentativ aufgestellt. Außerdem macht es die Projektaktivität deutlich besser sichtbar. Eine zusätzliche Website sollten wir nicht mehr benötigen. Falls wir diese Migration schaffen, lassen sich alle weiteren Probleme deutlich flexibler angehen. Die Frage nach regelmäßigen Releases oder Rolling Release dank CI lässt sich dann auch leichter beantworten. Grüße Stefan [1] https://bitbucket.org/ [2] http://code.google.com/p/gerrit/ [3] http://jenkins-ci.org/ [4] http://www.stack.nl/~dimitri/doxygen/ [5] https://www.atlassian.com/software/jira Am 18.10.2013 09:10, schrieb Hannes Menzel: > Hallo alle zusammen, > > In letzter Zeit ist REFLEX immer mehr unter die Räder gekommen. Selbst > das IHP setzt es immer weniger ein. Was sind die eurer Ansicht nach die > größten Probleme, die REFLEX hat. Bzw. woran liegt es, dass ihr es oder > andere nicht einsetzten. Wir > sollten demnächst versuchen, dem entgegenzuwirken. Das funktioniert aber > erst, wenn wir wissen, wo die Probleme tatsächlich liegen. > > Grüße, > Hannes >
signature.asc
Description: OpenPGP digital signature
