Tickets / Roadmap / Timeline

[Haeber]

Nur mal so nebenbei bemerkt und ohne den Hauch eines Vorwurfs.

Einiges was auch Leute ohne SVN-Zugang tun können.

• Patches nicht nur für die letzte stable sondern auch für den jeweils aktuellen trunk bereitstellen, einige der tickets mit patches funktionieren bspw. nicht mehr mit dem aktuellen trunk
• Patches als unidiff erstellen (geht bspw. bei svn automatisch beim Patch erstellen); dagegen sind hochgeladenen Dateien wo erst überprüft werden muss was sich tatsächlich geändert hat enorm zeitaufwendig zu überprüfen.
• die Patches können, wenn sie einmal hochgeladen wurden von jedermann getestet werden, und dann im ticket entsprechend kommentiert werden (bspw. yes this works, confirmed, (not) compatible from r15xx ...) das erspart den Entwicklern viel Arbeit.
• Übersetzungen werden in der Regel innerhalb einer Woche eingepflegt, da beispielsweise in meinen letzten commits mehr als zwanzig neue Strings hinzugekommen sind (die dt. habe ich bereits eingefügt), ist es schade das bisher keine einzige Fremdsprache entsprechend angepasst wurde.
• Der gestern von mir gefixte Bug in der hosting plan Bestellung blieb, obwohl er die Tarif-Bestellung unmöglich machte ganze 1 1/2 Monate unentdeckt. Ich nehme mal an das es hier nicht der Mangel an Entwicklern sondern der von Testern entscheidend war.
• Spenden sind (obwohl mir diese leider etwas intransparent sind) willkommen, sowohl finanziell, als auch bspw. mit Naturalien wie einem Server, damit könnte bspw. ein neuer Test-Server aufgesetzt werden. RatS der Hauptentwickler hatte bspw. vor einigen Tagen händeringend nach solch einem Test-Server gesucht. P.S.: Nochmal zum Thema Spenden, vielleicht kann hier mal jemand einen transparenten Guide für Spenden erstellen, derzeit wäre es für mich, wenn ich denn Geld auf der hohen Kante hätte, leider viel zu undurchsichtig was damit denn überhaupt passiert, bzw. inwiefern dies die Entwicklung verbessern könnte.
  

Noch einiges ans Team:
Vielleicht wäre es hilfreich ispCP im Timeboxing-Verfahren zu veröffentlichen, so wie es bei KDE 4.x geschieht. Soll heißen es gibt unabhängig von beabsichtigten Riesen-Implementierungen wie SSL jeden Monat einen Release. Das bedeutet SSL kommt, dann wenn es fertig ist, und verhindert damit nicht mehr das monatliche Release. Sobald eine solche große Änderung vorgenommen wird kann getrost die Major-Version erhöht werden bspw. für SSL ispCP 1.1 inszwischen können jedoch 1.0.1, 1.0.2, ... 1.0.9 etc pp. erschienen sein. Damit sind sicherlich viele Benutzer zufriedener, als andauern auf eine zigmal verschobene 1.0.1 mit SSL zu warten.

P.S.:
Kann bitte mal jemand die Listendarstellung dieses Forums korrigieren. Listen ohne Punkte oder Nummerierung sind nicht nur unleserlich sondern fern jeglichen guten Designs.

Grüße
Haeber