debianforum.de - Upgrade

[heisenberg]

Fortgesetzt von hier: Thread: phpBB 3.0.x ist EOL

Seit November 2015 ist die hier eingesetzte phpBB-Version(3.0.14) End-of-Life: Keine Updates, keine Security-Fixes.

Ich würde gerne die Aktualisierung von debianforum.de auf ein neues phpBB mit meinen Kenntnissen, Fähigkeiten und Resourcen unterstützen und Möglichkeiten zur Mitarbeit schaffen.

Da ich auf bisherige Arbeitsergebnisse wie Themes, Konfigurationen und weitere Details zum Setup keinen Zugriff habe und Kommunikation diesbezüglich mich dem auch nicht näher gebracht hat, schlage ich vor bei 0 zu beginnen.

An die Migration selbst kann es dann gehen, wenn das phpBB von den Funktionen her fertig ist. Was ich insgesamt nicht weiss, welche Komponenten eigentlich da so drin sind und wie das zusammenhängt(Authentifizierung? NoPaste? Planet? Wiki? Twitter? Links? Chat? SSO? LDAP?)

Diese Elemente fallen mir dabei so als erstes ein:

• GIT-Repo aus dem man eine aktuelle phpBB-Instanz mit der aktuellen Konfiguration und dem aktuellen Anpassungsstand erzeugen kann, oder sich sein eigenes Repo forken kann um eigene Änderungen zu testen und nach erfolgreichem Test per Pull-Request/Diff zurück zu mergen.
• Es gibt zumindest ein Master-Repo, dass aus dem aktuellen Revisionsstand täglich die phpBB-Instanz neu erzeugt.
• Einen VServer, auf dem sich jeder, der möchte, eine eigene phpBB-Instanz(eigener VHost) mit einfachen Mitteln erstellen kann
• Einen Bugtracker

Gibt es da Leute, hier Zeit und Kenntnisse haben und hier Interesse haben mitzumachen?
Habt Ihr weitere Vorschläge zur Umsetzung dieses Vorhabens?

[catdog2]

An die Migration selbst kann es dann gehen, wenn das phpBB von den Funktionen her fertig ist. Was ich insgesamt nicht weiss, welche Komponenten eigentlich da so drin sind und wie das zusammenhängt(Authentifizierung? NoPaste? Planet? Wiki? Twitter? Links? Chat? SSO? LDAP?)

• Das NoPaste ist in phpBB integriert, wohl irgendein Plugin, genauso wie die "neue" Gallerie.
• Planet wird von feltel manuell mit feed Adressen versorgt und dürfte komplett unabhängig sein.
• Beim Twitter Ding keine Ahnung, tippe auf irgendeine Art von RSS feed in Twitter Kipper. Wäre aber auch die Frage was da inhaltlich sinnvoll ist und evtl sollte man dann auch das feediverse (Gnusocial, Mastodon, etc…) bedienen.
• Das Wiki bedient sich meines Wissens aus der phpBB DB zur Authentifizierung, evtl steht in einem Thread zur Mediawiki Umstellung noch wie das Umgesetzt ist.
• Der XMPP Server hat seine eigene Benutzerverwaltung und ist damit ebenfalls unabhängig

[Luxuslurch]

Ich möchte, nach einem Überfliegen des Vorgänger-Threads, auch dazu anregen, das Vorhaben irgendwo (in jedem Unterforum?) ganz oben als Thread fest zu verankern. Denn die bemängelte Rückmeldung in der Testphase rührt IMHO daher, dass so gut wie keiner den Thread "phpBB 3.0 ist EOL" verfolgt hat, außer den Leuten, die irgendwas mit phpBB anfangen können. Also ich schon mal nicht.

[DeletedUserReAsG]

Letztlich hängt es am Admin. Solange der nicht mitmacht, kann man seine Zeit auch sinnvoller nutzen. Und je mehr Zeit vergeht, desto aufwendiger wird die Migration.

Meine bescheidene Meinung.

[heisenberg]

Letztlich hängt es am Admin. Solange der nicht mitmacht, kann man seine Zeit auch sinnvoller nutzen.

Sehe ich genauso. Zumindest ein Einverständnis und die tatsächliche Möglichkeit zur Datenübernahme wird zum Zeitpunkt der Umstellung benötigt. Sonst steckt man viel Energie rein und alles umsonst.

[Luxuslurch]

Letztlich hängt es am Admin.

Das wiederum habe ich als gegeben betrachtet. Ohne feltel geht natürlich gar nix.

[eggy]

@heisenberg: Du hattest auf die PM nicht geantwortet, daher war ich davon ausgegangen, dass Du die Daten von Feltel bekommen hattest.

@all:
Ich seh das so: Man muss ZEIT haben sich um sowas zu kümmern. Wenn man die nicht hat, wird es seine Gründe haben. Am Theme allein liegts wohl eher nicht. Auf dem CLT hatte Feltel mit dem "proof-of-concept" rumgespielt. Mein letzter Stand: Er schaut in wie weit sich das mit unseren "Produktiv"-Daten" verträgt. Aus meiner Sicht war das Theme zumindest in den Bereichen, die man offensichtlich sieht (mit Firefox auf sid) überwiegend ok, an anderen Ecken gabs aber noch genug zu tun. Die Ecken muss man nur erstmal finden. Daher auch die Bitte um Tester.

Von null beginnen halte ich für überflüssig. Wer es trotzdem machen will: im alten Thread ist relativ weit vorne alles verlinkt was man braucht.
Aber bevor jetzt großartig in Aktionismus verfallen wird, lieber mal nachfragen woran es hängt.

Zu den Vorschlägen aus dem Thread:
- Vserver mit mehreren Versionen ist m.E. übertrieben.
- Git ist ne gute Idee - aber bitte nicht auf github. TRex macht ein git auf, ich schieb die Daten dahin, dauert aber nen paar Tage (am Wochenende hab ich Zeit für sowas, aber dieses Wocheende ist erstmal Tübix
- Automatisches Build: zuviel Tooling schadet. Lokaler Webserver mit php und mysql/mariadb(?) reicht völlig.
- Bugtracker ist ok, aber eigentlich reicht auch nen Thread oder besser noch ne Wikiseite hier. (Ich würd hierbei lieber auf nen "richtigen" Bugtracker verzichten, zusätzliche Hürde für Leute die "nur mal kurz" helfen wollen)

Einer sollte den Hut aufhaben, sonst arbeitet man an einander vorbei. Hutperson muss auch Leute treten, falls die ihren Zusagen nicht nachkommen.

Aus meiner Sicht wäre die richtige Vorgehensweise:
0. Jemand setzt nen Wikiseite auf der alle die was tun mal eintragen, incl Fähigkeiten und Zeit die sie zur Verfügung stellen wollen.
1. Feltel gibt mal nen Kommentar zum Stand der Dinge bzgl Migrationsvorhaben: geht die Forenumstellung überhaupt (nach meinem Stand wars oberflächlich problemlos - aber der Teufel steckt ja bekanntlich im Detail); sollte an "echten Daten" getestet werden, muss Feltel machen (Passworte/Datenschutz etc)
2. TRex macht nen gitrepro auf, ich schieb die aktualisierte Fassung vom Theme darein.
3. alle: Zusammenfassung der "Bugs" des Tests ins Wiki kippen
4. wer will: eigene lokale Testinstanz aufsetzen
5. alle: TODO-Liste/wiki updaten
6. wer will: eigene Testinstanz mit aktuellen Daten aus git befüllen
7. wer will: Rumfrickeln, Patch an Hutperson schicken, im Wiki vermerken was man grade macht/gemacht hat (damit Arbeit nicht doppelt passiert)
8. Hutperson: Patch aktzeptieren (oder auch nicht) ggfs git updaten (oder an gitadmin weitergeben)
9. Testserveradmin: Testserver aus Git updaten
10. alle: Testen (nicht nur die offensichtichen Ecken, auch Seiten auf die man normalerweise nicht klickt, andere Auflösungen, Mobilgeräte etc )
11. alle: while (bug) goto 5
12. Feltel: Server auf aktuelles Board umstellen
13. if (sieht falsch aus) goto 10
14. alle: freuen

Hab ich was übersehn/vergessen?


Ich schreib mal an ne PM an Feltel, ob er hier mitreden mag.

[Meillo]

@eggy: Ich finde das was du schreibst sinnvoll, insbesondere die Wikiseite.

Wenn ich mich selber anschaue, dann wird es unwahrscheinlich sein, dass ich eine lokale Testinstanz aufsetze, aber wenn eine irgendwo online laeuft, dann wuerde ich die schon auch gerne (mit w3m) testen. Ich denke, dass es mehr so Personen wie mich gibt. Daher faende ich es gut, wenn jemand eine oeffentlich zugaengliche Testinstanz (mit dem jeweils neuesten Stand aus dem Repo) betreiben wuerde. Das kann unabhaengig davon sein was du an Vorgehen vorgeschlagen hast. Das finde ich gerade das Schoene an freien Projekten: Sie koennen dezentral Wertvolles hervorbringen.

Im gleichen Zuge moechte ich anregen zusaetzlich zur Wikiseite einen Thread im Forum am Laufen zu haben wo man Bugs posten kann, die dann von einer der aktiveren Personen auf die Wikiseite uebertragen werden. Fuer viele hier wird das Forum der gewohntere Weg sein zu kommunizieren und dort kann man auch besser ueber Diskutieren, waehrend man im Wiki dann eher die Ergebnisse festhaelt. (Einen Bugtracker finde ich auch too much.)

[heisenberg]

@heisenberg: Du hattest auf die PM nicht geantwortet, daher war ich davon ausgegangen, dass Du die Daten von Feltel bekommen hattest.

Ich hatte bisher auch noch auf Antwort von Sebastian gewartet. Super wenn Du die Daten auch noch hast.

Git ist ne gute Idee - aber bitte nicht auf github.

Ich höre jetzt schon zum zweiten Mal die Ablehnung von github. Welche Gründe gibt es dagegen?

Meine Gründe für github sind:

• Einfache forks/pull-requests/merges möglich.
• Issue tracker enthalten
• Gutes und effizientes Webinterface

Natürlich kann man sich auch was eigenes aufsetzen(gitlab, pures git,...), wenn man sich das auch einfach machen kann. Solange da keine sensiblen Daten drin liegen, ist das für mich akzeptabel.

---

Den Vorschlag, sowohl Bugtracker, als auch Wiki und Forenthread parallel laufen zu lassen finde ich gut. Mit einem Forenbeitrag kann man sich ohne weiteres direkt beteilligen. Ein Bugtracker bietet dann mehr Möglichkeiten, damit zu arbeiten.

[TRex]

Jo. Also Schreibzugriff für andere kann ich bei mir nicht anbieten, zumindest nicht unkompliziert und schnell. Das sieht auf github anders aus. Es ist ja aber kein Problem, ein paar git-repos miteinander zu synchronisieren, macht euch also darum mal keinen Kopf. Wenn einer von euch das noch ungeborene git von mir zu github clont, habt ihr github.

Die zentrale Instanz ist weniger kompliziert als es so zu machen, dass *jeder* die *Möglichkeit* hat, es lokal aufzusetzen.

[heisenberg]

Ich kann gerne auch eine VM(gleich Stretch?) zum testen zur Verfügung stellen, falls benötigt. Den root Zugriff würde aber auf einige wenige beschränken, so dass man sich da nicht gegenseitig stört.

Es kann ja durchaus auch vieles parallel laufen. Wichtig ist für mich, dass es die Möglichkeit gibt sich zu beteilligen.

[eggy]

@heisenberg:

Es gibt ne ganze Menge Gründe, die aus meiner Sicht gegen Github sprechen:

a) das übliche "keine freie Software" (gitlab hingegen kannst du runterladen, verändern und lokal betreiben);

b) 1-Account-Zwang: Du darfst laut TOS nur einen (kostenlos) Account haben. Das bedeutet Trackbarkeit vom Feinsten. D.h. meine Arbeit als Softwareentwickler im Testlabor für Hamstertests und meine ehrenamtliche Tätigkeit als Webseitenentwickler des Anti-Hamstertestlabors laufen über den selben Account. Das erfreut doch beide Seiten gleichermassen
Dass ich dann nebenbei noch Patches bei Finfisher und Tor einreiche spielt dann auch keine Rolle mehr.

c) Dass es keinen offensichtlichen Realnamenzwang gibt, ist zwar löblich, hilft aber nichts, wenn Dich Deine Kollegen bei Hamstertest immer mit Vornamen ansprechen und Dein Chef "Danke, Herr Meier !" in den Issuetracker schreibt. Apropos Herr Meier: Mist, das wollte ich doch geheimhalten. Und jetzt bekomm ich auch noch dumme feministische Kommentare auf der "cooles coden für Mädchen"-Seite, ob ich nen alter Pädoonkel wäre, dabei wollt ich doch nur helfen. Und meiner lieben Frau Meier geht es auch nicht anders. Sie darf sich, jetzt nachdem bekannt wurde, dass ihr Account ner Frau gehört, täglich dumme Anmachsprüche gefallen lassen - und ihre Codecontributions werden jetzt auch viel häufiger rejected.

Ok, ein fiktiver Fall, es gab jedoch 2016 ne Studie zu dem Thema, ob man der glaubt oder nicht, sei dahingestellt.
Relevant ist einfach, dass Daten gestreut und verknüpft werden, die man vielleicht so nicht zusammengeführt haben möchte. Alte Arbeitgeber, aktuelle Arbeitgeber, Freizeit, Familie etc.

d) Es ist immer schlecht, wenn zuviel Zeug auf einer Plattform lagert - Wenn da jemand (oder sie selbst) temporär "den Stecker rauszieht" (falscher DNS etc reicht schon) ist nen Grossteil der Leute nicht mehr arbeitsfähig (ja, Code hat man lokal vorliegen, aber Bugtracker, Kontakte, etc nicht). Von permanent mal nicht zu reden (entsprechende Beispiele gabs ja in der Vergangenheit einige, nur bisher betraf "der Shutdown" immer nur nen Teil des Kosmos. Nächstes Mal wirds ungemütlich, aber "told you so".

e) Lizenzwirrwar - ka, ob sich das letztendlich geklärt hatte: vor nen paar Wochen gabs nen TOS-update was dazu geführt hat, dass nen paar Leute meinten, das sei mit diversen FLOSS-Lizenzen nicht mehr vereinbar und entsprechend die Repos dichtgemacht haben (ob das übertrieben war oder nicht, keine Ahnung, ich fand es nur undurchsichtig kommuniziert - hab mich aber auch nicht weiter drum gekümmert).

Gibt noch mehr zu meckern, mir reichen schon b) und a)

[feltel]

Soviel Asche mag es garnicht geben, wie es notwendig wäre, mir übers Haupt zu streuen. Ich weiß das schon ne ganze Weile das ich es hier hab schleifen lassen, auch wenn ich hier und da für viele vielleicht unsichtbar immer wieder aktiv bin.

Was das Upgrade angeht, ja es ist mehr als Zeit, es endlich durchzuziehen. Es gibt und gab mehrere Problemfelder, die mich bisher davon abgehalten haben. Ich will das einfach mal auflisten, wie der Stand der Dinge ist.

1. Datenübernahme phpBB 3.0.x zu 3.2.x
Die Migration läuft mittlerweile sauber durch, so das keine Informationsverluste beim Upgrade zu erwarten sind. Ein paar Usereinstellungen müssen im Nachgang angepasst werden, aber alles überschaubar.

2. Template
Das von Eggy entwickelte Template läuft, auf den ersten und zweiten Blick sind nur wenige Bugs sichtbar. Das sollte uns also nicht vom Upgrade abhalten. Man könnte dann im laufenden Betrieb ein Template komplett neu aufbauen, gerne auch mit einer neuen Designsprache.

3. Plugins
Hier gibt es die größten Probleme. Wir haben die folgenden Plugins im Einsatz: MediaWiki-Userintegration/Bridge (OK, gibt es in neuer Version), Galerie (Entwicklung eingestellt, kein Nachfolger in Sicht, damit keine Datenübernahme), NoPaste (tlw. OK; Plugin für phpBB 3.1.x läuft so lala) Tapatalk (OK, gibt es in neuer Version)


Wie ihr seht ist der Bereich Plugins derjenige, der mir die meisten Bauchschmerzen macht. Nichtsdestotrotz würde ich jetzt die Migration durchziehen, auch wenn dann erstmal absehbar ein paar Features wegfallen. Ich habe ab Mitte der kommenden Woche zwei Wochen Urlaub und da werd ich das ganze durchziehen.

Den Vorschlag mit einem dezentralen Repo für die Entwicklung finde ich zwar einerseits reizvoll, aber auf der anderen Seite gibt es hier nur eine ganz eng begrenzte Codebasis, die wir anfassen. Ich versuche schon immer so wenig wie möglich Code zu ändern, um das ganze so wartungsfrei zu machen, wie es nur geht. Wenn wir jetzt hier viel mit sustom Code operieren oder einem Repo, dann ist das meiner Meinung nach viel zu viel administrativer Overhead.

[eggy]

@Feltel: ich denk, die Idee die nötigen öffentlichen (!) Daten in nem Git vorzuhalten ist gut. Vorausgesetzt, dass sich jetzt Leute finden, die das auch langfristig mittragen - denn die "nächste Boardanpassung" kommt bestimmt.

@all:
Ich hab ne Seite im Wiki angelegt https://wiki.debianforum.de/Dfdebugtrackerchen
Freiwillige vor!

[catdog2]

Zumindest für sowas wie das Theme halte ich ein git mit dem aktuellen Stand auch für eine gute Idee. Ich denke da sind die Chancen auch größer, dass sich mal jemand ran wagt. Nachfragen und im schlimmsten Fall Tage warten zu müssen ist schon eine Große Hürde, wenn man mal spontan Lust und Zeit hat.

[eggy]

Grade in Bezug auf "was macht diese Änderung im css eigentlich genau? Wen der vorherigen Leute kann ich fragen? Und brauch man das beim nächsten update eigentlich noch" wärs ganz nett ne Commithistory zu haben.

[feltel]

In Sachen Gallery scheint es doch weitergehen zu können: https://github.com/satanasov/phpbbgallery/tree/1.2.1

[Sv3n]

Ist es nicht so das die Gallery nicht kompatibel mit der Version 3.2 ist?
Ich werde mal auf die Suche gehen, und wenn ich was negatives finde gebe ich Bescheid.

[feltel]

Die 1.2.1-Branch sollte die für phpBB 3.2 passende sein. Getestet hab ich es aktuell allerdings nicht.

[Sv3n]

Ich würde mich heute Abend mal dazu bereit stellen phpbb3.2 mit der Gallery zu testen.
Aber was ich bis her noch nicht gefunden habe ist eine Integration Wiki - phpbb3.2.

Wenn noch weitere test anstehen sollten, wäre ich gerne bereit diese zu testen.
Dazu dann ebend Bescheid geben was getestet werden soll.!

[feltel]

https://www.mediawiki.org/wiki/Extensio ... ntegration

[Sv3n]

https://www.mediawiki.org/wiki/Extensio ... ntegration

Soll ich das mal mit testen?

[feltel]

Gerne, wenn Du ne Spielinstallation dafür hast.

[Sv3n]

Habe noch einen dummy Server, da kann ich das machen.

[Sv3n]

So hier kommt schonmal ein Nachtrag, das sich aus dem Test ergeben hat.

phpBB3.2.0 erfolgreich installiert auf Basis von php7.
Daruf hin habe ich die Gallery (die aus dem obigen Link genommen)
Ich sehe gerade, php7, geht die Gallery nicht, also habe ich wieder auf php5.6 umgestellt, dann ging Sie

• Die Gallery ist noch nicht komplett für PHP 7.x geeignet

Wiki läuft Problemlos soweit alles Bestanden.