SourceForge beendet Unterstützung für Hosted Apps => kein Wiki mehr

[Chris M.]

Wie man unter Hosted apps retirement | SourceForge Community Blog und mit weiteren Details auf Forge / community docs / Hosted Apps Retirement beschrieben, wird SourceForge die Unterstützung für Hosted Apps beenden.

[ACHTUNG]Das heißt für uns, unser Wiki (also die Homepage und die Doku) können wir so nicht mehr weiterführen![/ACHTUNG]

Da natürlich viele Projekte davor stehen, wird es sicher Anleitungen für sinnvoll gangbare Alternativen geben.

=> Wer kann und mag sich hier um die Details und ggf. ein neues Konzept kümmern?
(Auch ohne Programmier-Wissen kann man sich so gut bei unserem Projekt einbringen!)

[swiss]

Hallo Chris

Oo Dass sind aber gar keine guten Nachrichten

Hmmm... Wehm gehört die TLD cometvisu.org?

Wäre selber Hosten eine Lösung? Ich hätte da schon eine Idee aber ich möchte erst mal eure Meinung hören.

Geht es nur um das Wiki oder soll gleich richtig umgestellt werden mit einer Projektpage und Wiki. Die Entwicklung würde ja weiterhin über SF Laufen aber es wäre eventuell nicht mehr erste Anlaufstelle für den Endanwender.

EDIT: Und gibt es eine Möglichkeit ein Backup des gesammten Wiki als Datei zu erhalten?? Oder heist es Copy Paste für jede einzelne Seite?

[Chris M.]

Oo Dass sind aber gar keine guten Nachrichten

Das ist halt der Nachteil wenn man sich auf andere verlässt - aber andererseits muss man auch ganz klar sagen: wir haben dadurch richtig viel Arbeit gespart!
Also lasst uns nicht böste seib, dass das weg fällt, sondern dankbar, dass es bis jetzt funktioniert hat und sich jemand anderes um die Administration gekümmert hat!

Hmmm... Wehm gehört die TLD cometvisu.org?

Mir und läuft über einen reinen DNS Provider. Ist also absolut flexibel, nur kein Web-Server dahinter. Und selber hosten möchte ich nicht (auch wenn ich könnte...), da ist mir der administrative Aufwand zu hoch

Wäre selber Hosten eine Lösung? Ich hätte da schon eine Idee aber ich möchte erst mal eure Meinung hören.

Nur wenn sich jemand zuverlässig um die Administration kümmert. Das ist deutlich mehr Verantwortung und Verpflichtung als SVN Schreibzugriff zu haben und mal einen Patch zu posten.

Geht es nur um das Wiki oder soll gleich richtig umgestellt werden mit einer Projektpage und Wiki.

Ich würde nur das MediaWiki umziehen. Den Rest so lassen, wie er ist.
Aber selbstverständlich bin ich für Diskussionen offen, insb. bei der Meinung des Freiwilligen .

EDIT: Und gibt es eine Möglichkeit ein Backup des gesammten Wiki als Datei zu erhalten??

Davon gehe ich sehr stark aus. Lass die SF-Jungs noch ein paar Tage arbeiten und dann mal auf https://sourceforge.net/p/forge/comm...%20Retirement/ schauen, was empfohlen wird.

Wir können sicher auch MediaWiki auf der SF Projektseite installieren. Dazu sollte es bereits jetzt schon Infos geben, das kann man schon die ganze Zeit machen...

[teichsta]

ich habe sehr gute Erfahrung mit GoogleCode gemacht. Da hast Du auch alles, was Du brauchst ...

Gruß,

Thomas

[swiss]

Hallo Chris

Naja das MediaWiki selber zu hosten ist nicht dass grosse Problem. Wenn dann sowiso in einem RZ und nicht zuhause. Dann hält sich warscheinlich auch der administrative Aufwand in Grenzen. Die Devise würde dann lauten... Never touch a running System.

Aber wenn es sich auch in SF wieder installieren lässt... Wiso nicht?

Wenn sich niemand findet, würde ich das Patronat für das Wiki übernehmen Host wäre auch vorhanden.

[AScherff]

aehhm...

einen virtuellen Apache können wir gern zur Verfügung stellen...

[greentux]

code.google.com wäre wohl schon ganz passend. Ggf noch Launchpad.

Wenn dann sollte das ganze Projekt umziehen und nicht "Code hier" und "Wiki da" und am Ende "Tracker dort"...

[MarcusF]

github gibts auch noch und ist gefühlt eh schneller als SourceForge.

Marcus

[dombn]

Eine Umstellung auf git würde ich sowieso begrüßen. ) Wäre das nicht etwas?

[Chris M.]

ich habe sehr gute Erfahrung mit GoogleCode gemacht. Da hast Du auch alles, was Du brauchst ...

Bei SF an sich auch - der Unterschied dort ist nur der, dass eine gemaintainte Installation von MediaWiki wegfällt und bei Bedarf selber installiert werden müsste. Den WebSpace (-> https://sourceforge.net/apps/trac/so.../Project%20web) und die Datenbank (-> https://sourceforge.net/apps/trac/so...ect%20database) gibt's dort - es muss nur gemacht werden.

Das ist jetzt weder für noch gegen GoogleCode zu verstehen!

Am Schluss muss es einfach funktionieren. Ich will hier die CV weiter bringen und nicht Zeit in der Administration versenken.
Zum Weiterbringen gehört aber auch eine für End-User gut zugängliche Homepage mit Doku - IMHO per MediaWiki sehr gut zu machen, die Infrastruktur von GoogleCode finde ich da eher unübersichtlicher. Die ist IMHO zu sehr auf Entwickler und nicht auf Anwender ausgelegt.

Naja das MediaWiki selber zu hosten ist nicht dass grosse Problem. Wenn dann sowiso in einem RZ und nicht zuhause. Dann hält sich warscheinlich auch der administrative Aufwand in Grenzen.

RZ bietet auch SF AFAIK. s.o.

Die Devise würde dann lauten... Never touch a running System.

Da muss man aufpassen. Auch bei MediaWiki werden inzwischen Lücken gesucht und gefunden. D.h. da muss man schon aufpassen und Patchen...

Wenn sich niemand findet, würde ich das Patronat für das Wiki übernehmen Host wäre auch vorhanden.

Sehr gerne!

aehhm...

einen virtuellen Apache können wir gern zur Verfügung stellen...

Vielen Dank für's Angebot! Aber ich glaube am Apache mangelts nicht - sondern an der kontinuierlichen Pflege des MediaWikis...

Wenn dann sollte das ganze Projekt umziehen und nicht "Code hier" und "Wiki da" und am Ende "Tracker dort"...

Mischen halte ich auch für suboptimal.
Eine Homepage könnte aber durchaus wo anders liegen, die würde die SF-Projektseite ja einbinden können, vgl. aktuelle Seite.
Aber gerade das Wo ist ja nicht das Thema. Das Wie müssen wir zuerst klären...

Eine Umstellung auf git würde ich sowieso begrüßen. ) Wäre das nicht etwas?

Auch da bin ich prinzipiell offen, auch wenn ich Git noch nie genutzt habe. Doch abgesehen davon, dass uns ja nicht SourceForge komplett wegbricht (nur der Service der zentral gehosteten Apps!) wirst Du sicherlich verstehen, dass ich bei der Wahl des Versioning-Tools die Meinungen der Leute nach der Menge des bereits beigetragenen Codes gewichte.

Was wir am letztendlich machen wird ein Kompromiss (oder besser: Konsens) zwischen allen beteiligten Parteien sein. Das ist insb. auch der "Administrator", die aktiven Entwickler und die User. Ob und wenn wie stark ich ordnend und gewichtend eingreifen werde, hängt ganz davon ab, wie die Diskussion läuft. Am besten wird's nicht relevant werdend, da alle den gleichen Konsens wollen

[greentux]

Die Geschwindigkeit von SF war schon immer irgendwie lahm gegenüber den anderen Kandidaten.

Die Wikiseiten sind zwar bei Google anders strukturiert, aber man sollte den Anwender auch nicht unterschätzen (wie auch beim Editor). Der blickt das schon denke ich.

[swiss]

Naja ein richtiges MediaWiki hat natürlich auch erweiterte, gestalterische Möglichkeiten um das ganze etwas ansehnlicher zu machen. Wie es da bei Google aussieht weiss ich nicht.

Ich werde auch mal noch die Optionen durchsehen. Das Wiki (wo auch immer) hat den Vorteil, dass alle Datensätze übernommen werden können. Sonst müsste man sämtlich Seiten in ein neues System einpflegen. -> Nicht soo toll

@Chris: Wir sehen uns ja spätestens am 21.06 Da findet sich bestimmt auch zwischen durch noch Zeit zum Gedankenaustausch bezüglich Neuorganisierung und Arbeitsaufteilung


PS: Wird cometvisu.de auf den DNS-Servern von elabnet gehostet? Wenn ja... Könnte man da nicht eventuell eine Subdomain einrichten für das Handbuch? Die Frage stelle ich aus folgendem Grund...

Das Handbuch ist momentan über einen Link aus dem Editor aufrufbar und ist Statisch auf SF verlinkt... Dass ist durch die Abschaltung problematisch, da dann bei allen schon im Einsatz befindlichen CV's der link plötzlich Broken ist Wenn man da aber eine Subdomain zwischenschaltet, kann man den Host jederzeit umziehen und der Link bleibt immer gültig. So könnte www.cometvisu.de auf das Projekt im SF zeigen und z.B. manual.cometvisu.de auf das Wiki dass sich dann irgendwo befinden kann. Oder denke ich zu kompliziert?

[Chris M.]

@Chris: Wir sehen uns ja spätestens am 21.06 Da findet sich bestimmt auch zwischen durch noch Zeit zum Gedankenaustausch bezüglich Neuorganisierung und Arbeitsaufteilung

Klingt gut, zumindest falls Du gerade Dich vertippt haben solltest

PS: Wird cometvisu.de auf den DNS-Servern von elabnet gehostet? Wenn ja... Könnte man da nicht eventuell eine Subdomain einrichten für das Handbuch? Die Frage stelle ich aus folgendem Grund...

cometvisu.de - guter Punkt. Die hab ich total vergessen. Die gehört mir auch nicht, sondern elabnet. D.h. hier muss Makki und/oder StefanW sagen, was damit passieren soll, insb. da die inaktiv ist

Mir gehört cometvisu.org - und was da alles möglich ist, müsste ich nachsehen. (Zur Info: ist bei united domains)

Aber vermutlich sind Subdomains möglich. Und da können wir gerne beliebig viel Schindluder mit treiben

[swiss]

Hallo Chris

Ja hab mich vertippt Ist der 21.07

Wegen der Subdomain für's Handbuch...

Ich habe gerade bei united Domain's nachgesehen und dort steht, dass man beliebig viele Subdomains mit verschiedenen Zielen einrichten kann. Das wäre doch eine gute Lösung z.B. manual.cometvisu.org

Unterhalb Ihrer neuen Domain können Sie beliebig viele Sub-Domains im Format "sub1.meinedomain.de", "sub2.meindomain.de", usw. einrichten. Jede Sub-Domain kann auf eine andere Ziel-Adresse weitergeleitet werden. Sie können also jede Sub-Domain einzeln nutzen und z.B. auch jeweils andere Inhalte hinterlegen.

Damit könnte man zur Not auch mehrere male mit dem Handbuch umziehen (wenn wirklich nötig) und hätte immer einen gültigen Link in der CV Sonnst müsste man immer ein Releas machen um den Link wieder anzupassen

[Chris M.]

So, jetzt gibt's manual.cometvisu.org und handbuch.cometvisu.org