Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • makki
    antwortet
    Ich bin ja dehnbar
    Also sollten keine besseren Vorschläge kommen, ein Mediawiki auf eigenem Server? (die Rechteverwaltung kann nun auch nicht kruder werden, als sie in SF war )Dann schau ich mir das mal an..
    Es muss halt nutz&pflegbar sein, ich wünsche mir z.B. einfach eine eMail bei Änderungen - Push, nicht pollen - aber den Wunsch kann ich mir dann ja selbst erfüllen

    Den Source/SVN würde ich aber wiegesagt dort auf SF belassen, passt IMHO..

    Makki

    Einen Kommentar schreiben:


  • swiss
    antwortet
    Naja das Wiki hat den Vorteil, dass mehrere daran arbeiten können. Ich hätte aber am liebsten ein vollständiges Mediawiki auf einem eigenen Server.

    Einen Kommentar schreiben:


  • makki
    antwortet
    Zitat von Chris M. Beitrag anzeigen
    cometvisu.de - guter Punkt. Die hab ich total vergessen.
    Die wurde nur geblockt, weils fast nix kostet wenn man kann (Also neben RIPE/LIR, Denic, KNX in vielen komischen Vereinen Mitglied ist..)
    Es ist aber einfacher sie halt mal zu haben, als wenn man sie sich später erstreiten muss..
    (Ein bisschen Glaube gehört auch dazu, ich glaube )

    -> Die Domain(s) stehen aber ausdrücklich der CV zur Verfügung!

    Ich war ein bisschen weg, also conclusion ist das auf SF weiter zu pflegen und Link?
    Server, mein Favorit wäre Trac, soll nicht das Problem sein. (gibts seit Tag 1 fürs WG -nur alleine macht das keinen Sinn )
    Source würde ich aber da lassen wo er ist, auf SF, das Wiki, ehrlichgesagt fand ich schon immer sperrig und bin eher froh das es tot ist -> für bessere Vorschläge bin ich gerne offen - und wenns dafür ne VM braucht sollte das auch kein Thema sein..
    Bitte einfach die Wunschliste einkippen, die Jahre haben einem gelernt das SF, Google&Co halt - naja - nicht immer so toll sind.

    Allen Wolken (Clouds) hin oder her bin ich immernoch der Typ der gerne seine Daten auf seiner Festplatte (gehört mir!) unter seinem Schreibtisch (oder in seinem Rack) hat. Denn da ändert sich so erfreulich wenig, solange man das nicht will

    Makki

    Einen Kommentar schreiben:


  • swiss
    antwortet
    Jup

    Dass würe aber als Übergangslösung eine Art "Startseite" nicht ausschliessen

    Der momentan englische Editor wird fix mit manual.cometvisu.org verknüpft und bis es einen deutschen Editor gibt, zeigt manual.cometvisu.org nicht direkt in das englische Handbuch sondern eine Auswahlseite. So hätte man immer die nötige Flexiblität und könnte den deutschsprachigen Usern trotz fehlender multilingualität im Editor das deutsche Handbuch zugänglich machen

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Ich würde naiv und einfach ran gehen:

    Der Editor muss eh multilingual werden, d.h. eine i18n bekommen (freiwillige?). Und dann legt man einfach den Link auf das Handbuch in den zu übersetzenden Strings mit ab => jeder bekommt Englisch solange es nicht auf was anderes übersetzt wird

    Einen Kommentar schreiben:


  • swiss
    antwortet
    Sehr gut.

    Die Frage ist noch, wie es genau in der CV gehandhabt werden soll. (multilingual) Je nach dem müsste ja auf die eine oder andere Subdomain verwiesen werden.

    Oder wir machen für das Handbuch Wiki-intern eine "Startseite" auf der man die jeweilige Sprache auswählen kann. Das hätte den Vorteil, dass man sich nicht CV intern darum kümmern müsste. Es gäbe dann nur eine Subdomain...

    Über das Konzept müsste man nochmal nachdenken. Aber der grundsätzliche Einsatz der Subdomain(s) für das Handbuch hat sicher einige Vorteile da niemand weiss was die Zukunft bringt

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    So, jetzt gibt's manual.cometvisu.org und handbuch.cometvisu.org

    Einen Kommentar schreiben:


  • swiss
    antwortet
    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

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Zitat von swiss Beitrag anzeigen
    @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
    Zitat von swiss Beitrag anzeigen
    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

    Einen Kommentar schreiben:


  • swiss
    antwortet
    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?

    Einen Kommentar schreiben:


  • greentux
    antwortet
    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.

    Einen Kommentar schreiben:


  • Chris M.
    antwortet
    Zitat von teichsta Beitrag anzeigen
    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.
    Zitat von swiss Beitrag anzeigen
    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.
    Zitat von swiss Beitrag anzeigen
    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...
    Zitat von swiss Beitrag anzeigen
    Wenn sich niemand findet, würde ich das Patronat für das Wiki übernehmen Host wäre auch vorhanden.
    Sehr gerne!
    Zitat von AScherff Beitrag anzeigen
    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...

    Zitat von greentux Beitrag anzeigen
    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...
    Zitat von dombn Beitrag anzeigen
    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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


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

    Marcus

    Einen Kommentar schreiben:


  • greentux
    antwortet
    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"...

    Einen Kommentar schreiben:

Lädt...
X