Sollte das Wiki Entwicklerseiten spiegeln?

Auf der Opensourceecologyseite wird z.B. Filamaker als inaktiv angezeigt , obwohl dort die letzte Bearbeitung von Oktober ist und das letzte Update von Marcus noch nicht lang her ist. Könnte das viele „Inaktiv !“, obwohl daran geforscht wird, nicht ein falsches Licht auf uns werfen?

Allgemein ist es nicht einfach, unsere Informationen im Wiki ordentlich und aktuell zu halten. Wäre es nicht von Vorteil, neue Entwicklungen oder Nachrichten dort von der Entwicklungsseite zu spiegeln (z.B. von thymark.com, etemu.com, github, …).


Daher stelle ich folgende Idee zur Diskussion:

Wie wäre es, die Wiki-Seiten möglichst automatisch zu generieren? Wir müssten dafür auch nicht ubnedingt einen eigenen Generator schreiben, sondern würden vielmehr einfach mittels HTML (oder etwas unbekannter aber z.B. in Foren von Vorteil: ) die jeweilige Entwicklungsseite direkt einbinden. Seiten mit hoher Medienlast vielleicht zunächst versteckt in einem Spoiler zum Ein- und Ausblenden auf Wunsch?

Dann hätten wir das beste von beiden Seiten: Neuigkeiten, BOM, Spezifikationen, … alles auf dem aktuellsten Stand* im Wiki und gleichzeitig noch die Möglichkeit, seine eigenen Entwicklungsdateien in einem Versionierungssystem zu halten. Natürlich hat auch ein Wiki ein Versionierungssystem, aber das Dateihandling ist viel zu umständlich. Wie soll man z.B. eine Exceldatei die man ins Wiki hochgeladen hat und dort irgendwo in der Datenbank herumfliegt direkt dort bearbeiten? Es ist mir zu kompliziert, denn das Ziel bei Open source sollte sein, dass man sich e i n e Quelle hält und a l l e daran weiterarbeiten können. Man kennt das ja, was passiert, wenn man Dateien mehrfach anlegt oder wenn mehrere Leute je eine Kopie bearbeiten und hochladen … was für ein Chaos und verlorene Daten - wenn man nicht merged. Das Single-Source-Prinzip denke ich, ist der Schlüssel zum Erfolg eines Open-source Projekts, denn diese Art Projekte versinken schnell im Chaos. (aber auch nicht -open-source Projekte an z.B. Unis, wenn man sich von Hierarchien nicht lösen kann. Hierarchien z.B. bei der Erlaubnis Dateien zu bearbeiten, dann geht der Spass nämlich erst los, weil alle nur Read-only/ausschließlich-Lese-Rechte haben, legen dann alle Kopien an und arbeiten da weiter. Oder alle rennen zum anderen, weil sie noch einen Account von dem brauchen oder Rechte hier und da, sonst kämen sie nicht weiter. Währenddessen wartet ein anderer darauf, dass es der andere dort Rechte bekommt. Und wenn nun ein Vierter kommt und eine Aufgabe lösen soll, dann sucht dieser natürlich nach den passenden Readonly-Dateien und findet … je fünf verschiedene Varianten. Welche wird er wohl kopieren (denn er hat ja auch nur readonly-Rechte)? Nennen wir es herzliches durcheinander? Also ich bleibe bei Open source … keine Hierarchien.)


*Auf dem aktuellsten Stand deswegen, weil durch eine geschickte Kombination von Mercurial Versionierungssystem bei der Entwicklungsseite und dem Spiegeln/Einbinden dieser Seite im Wiki jede Änderung sofort im Wiki reflektiert würde.


Hier zwei Alternativen wie das aussehen könnte:
z.B.
—VARIANTE 1----

  1. Server: Dateisystem: HTML Dateien für Webseite und Entwicklungsseiten. Mercurial kann diese Seiten versionieren, OHNE dessen Struktur zu verändern und ist im Gegensatz zu SVN auch für Binärdateien geeignet, also vereint die Vorteile von Git und SVN.

  2. Die Serverdateien bindet man sich zur Weiterentwicklung im Linuxsystem ein, damit man sie auch mit den dort installierten Programmen öffnen kann. Das hat den Vorteil, dass man auch mal schnell entweder vom Laptop o d e r vom 3D-CAD fähigen Quadcore arbeiten kann.(ich hab weder noch lol.)

Das Einbinden funktioniert z.B. über das Paket SSHFS (also per ssh) wenn man mit der Kommandozeile umgehen kann und will.
Oder, wenn man die Dateien auf dem Desktop direkt als Ordner verfügbar haben will und auch für eine Serververbindung einfach nur per Klick öffnen will: per Linux Option: „Verbindung zu Server“ oder so ähnlich (hängt von der Linuxdistribution ab, ob es vorinstalliert ist. Findet sich aber bestimmt ein GNU-UNIX-Paket für jeden Linux-Geschmack (also auch Android oder MAC OS, was nichts anderes als Linux ist, und nur eine andere Oberfläche hat) im Netz).

3.)
Will man nur mal schnell ein paar Kleinigkeiten ändern, oder Dateien (z.B. neue Bilder) hizufügen, müsste man aber nichtmal die Serverdateien einbinden. Dann reicht das SSH SCP Kommando bei Linux oder Filezilla oder WinSCP (das ich sehr gelungen finde, obwohl ich Linux-Fan bin) oder jeder x-beliebige andere FTP/SCP-Client.

—VARIANTE 2----
Einzige Änderung bei 1:
0) Versioniert wird auf dem lokalen Arbeitsrechner. (z.B. Entwickler-Laptop)

  1. Man hält sich einen Server/einen Webauftritt. Dort lädt man die aktuellsten Dateien nach jeder Änderung hoch.

  2. Weiter wie in Variante 1: Diese Änderungen werden im Wiki gespiegelt …

    \


Ein Makel ist, dass das Design nicht passt, aber das ließe sich ja über GET-Parameter im Link den man beim Einbinden verwendet ändern. Z.B. könnte man so alles Styles entfernen oder das Opensourceecolgoy-Stylesheet wird dann automatisch und nur für’s Einbinden ins Wiki verwendet. (Kommt auf die ContentManagmentSysteme an, die unsere Leute verwenden. Ich verwende gar keins, und halte CMS für einen Grundsatzfehler , denn ein Dateisystem ist eigentlich schon ein solches System. Bei mir spiegeln Webseiten immer das Dateisystem, das einzige was ich noch mache, ist Ausnahmen definieren, welche Dateien nicht angezeigt werden sollen. Neuer Inhalt wird erstellt, indem ich einfach eine Datei (z.B. php oder html) im Dateisystem auf dem Server erstelle- das erscheint dann automatisch als Menüpunkt auf der Webseite. Kein CMS installieren und auch keine Datenbank-Engine.)

Ich hoffe, ich habe mit meiner Content-Management-System-Abneigung niemanden persönlich angegriffen, das war nicht meine Absicht und ich bitte dann um Entschuldigung! Diese sind heutzutage immerhin Standard und meine Meinung ist hochgradig subjektiv.

Deswegen habe ich auch die VARIANTE 2 hinzugefügt.


Was haltet ihr also vom Spiegeln einzelner Entwicklerseiten - z.B. der letzten 10 Commits ins Versionierungssystem?
jan

I have just talked to Marek (thymarks.com) and he told me that he also wants it to be automated as much as possible. He said it is impossible to keep too many sites up to date.

He also told me of the new FilaPuller and that he has a spare 3D printer with a new heatplate, because the old one needed much too much time for heating ABS … so if anyone is interested.


I currently work on an example setup (SingleSource<->Mercurial<->Wiki) for the Waterfall project. There are still many problems as I have no root access to my webspace, but I’m working on solving that at the moment.

Danke Jan! Ich lese heute deinen Vorschlag beim Stammtisch:http://etherpad.mit.edu/p/OSEG-stammtisch-4 . Filamaker habe ich aktiviert.

Hi Jan. Jeder OHSW-Entwickler kann sich selbst entscheiden, wo er seine Dokumentation veröffentlichen. Wir werden einfach auf die entsprechende Seite verlinken. So wie mit dem FilaMaker und Carla:http://wiki.opensourceecology.de/Open_Source_Ecology_Germany/Spenden . Das Wiki ist noch nicht entsprechend strukturiert, aber das ist das Ziel. LG, Nikolay

Hallo Nikolay, das ist eine gute Lösung. Wir müssen nichts von der Stange brechen, wenn’s nicht geht. Ich habe jetzt auch zwei Tage durchgehend damit verbracht, Mercurial auf meinem Webspace ohne Adminrechte zum laufen zu bringen …

Ich hab alles aufgeschrieben, damit es vielleicht dem ein oder anderen hilft. Im Wiki: How to install Mercurial (hg) without Root access.

Da werde ich in Zukunft meine versionierten Projekte entwickeln und dann in unserem Wiki spiegeln, wenn alles gut geht. Sozusagen als Probelauf oder ‚proof of concept‘, wer weiß ob’s überhaupt klappt.