(08.08.2014 14:50)Eddi schrieb:  Aber genau sowas meine ich. 32bpp war niemals "Ziel". 32bpp passierte nur, weil sich mal einer hingesetzt hat, und das brauchbar implementiert hat. Solche "Ziele" bleiben einfach nur "Wünsche", solange sich keiner hinsetzt, und die tatsächliche Arbeit tut. Und weil man das nicht steuern kann, gibt es eben keine "Ziele", sondern nur "Wünsche" (und ggf. "Nicht-Ziele")

Aktuelles Beispiel: Ich hab das Patch für Fahrpläne mit absoluten Zeitangaben geschrieben, irgendwann den unbedingt nötigen Teil extrahiert damit es kleiner wird.

Grade aktuell hab ich gemerkt dass sich irgendwer hingesetzt hat und den bestehenden Code im trunk (auf ich glaube durchaus sinnvolle und nachvollziehbare Weise) refactored hat.

Für mich bedeutet das jetzt natürlich wieder dass ich mich auch hinsetzen muss und meine patch queue an die entsprechenden Änderungen anpassen muss (da es grob gesagt meinem jetzigen Verständnis nach um die Umwandlung von Direktzugriffen auf Variablen in Funktionsaufrufe, nebst einer weiteren explizit NOSAVE gecachten Variable geht ist das auch wirklich ein Querschläger der ein Überarbeiten des kompletten Patches erzwingt) --- die Alternative wäre, in den Status "ich bin mit OpenTTD in der derzeitigen Version zufrieden und ignoriere zukünftige Änderungen, sondern spiele nur noch auf der aktuell gepatchten Version" überzugehen.

Was ich sagen will: Sowas macht Arbeit, und da fände ich es schon sinnvoll wenn man sich mal auf eine Roadmap in dem Sinn einigen könnte dass man als Patch-Entwickler der eine selbsterkannte Schwachstelle im Spiel verbessern möchte weiß auf welches Ziel man hinarbeiten kann / soll. (also, deutlicher gesagt, Roadmap auch gerne (nur) in dem Sinn dass die enthaltenen Punkte schon mit jemandem besprochen sind der auch daran aktiv daran arbeitet, weil dass es so jemanden braucht ist mir auch klar, eine Wunschliste ist ganz klar eine andere Kategorie).

In dem Fall ist die Schwachstelle dass ich es unwartbar fand, einen Fahrplan rein auf Reisezeiten basieren zu lassen, was meiner Erfahrung nach bei Änderungen regelmäßig zu Problemen führt, und außerdem bei größeren, aufeinander abgestimmten Linienführungen schon fast Buchführung außerhalb des Programms erzwang (z.B. wenn ich einen Taktknoten gestalte der auf bestimmte Weise von verschiedenen Linien angefahren wird). Schlussfolgerung meinerseits damals als ich das Patch angefangen habe: Ich brauch Fahrpläne in Form von Zugläufen sowie Bahnhofsfahrpläne wie in echt, wo absolute Zeiten drinstehen.

Ich denke, auf Basis so einer Analyse (hier nur ganz grob skizziert) kann man diskutieren, und im Idealfall weiß dann der Patch-Entwickler irgendwann ob 1. seine Arbeit einen Sinn hat, und 2. wie er ggf. weiterimplementieren kann. Und 2. kann man denke ich durchaus als Roadmap gezogen auf ein Patch sehen. Wenn 2. und der Patch-Entwickler die nötige Zeit reinstecken kann ist man im Idealfall in endlicher Zeit soweit dass man die Sache als fertig betrachten kann.

(oder anders gesagt: Ich finde man sollte unterscheiden zwischen aktuell erkannten Schwachstellen des Patches (hier passt die Benutzerführung noch nicht, da gibts eine Konstellation wo es abstürzt, so banale Dinge), und den Zielen wo man hinwill - letztere kann man auch diskutieren, solange bei ersteren noch Handlungsbedarf ist)

Aus eigener Erfahrung kann ich nämlich sagen: Rein aus dem fortwährenden Anpassen eines Patches an Änderungen im Trunk ergibt sich ein nicht zu vernachlässigender Arbeitsaufwand, alle paar Monate ein oder mehrere Abende bis alles wieder so läuft wie vorher ist da einfach realistisch.

Gegeben das nervt es einfach manchmal das Gefühl zu haben, ich arbeite da dran, und da gibts irgendein Orakel dessen geheimen Wünsche ich nicht genau kenne aber vielleicht irgendwann mal treffe. (jetzt etwas überzeichnet gesagt)