(15.04.2017 09:44)Eddi schrieb:  

(14.04.2017 17:22)ic111 schrieb:  Ja, bis zu einem gewissen Grad geht es wohl um einen Perfektionismus, den man in einem Hobbyprojekt einfach häufig realistisch nicht erfüllen kann.

Hier möchte ich gerne widersprechen. Es geht den OpenTTD-Entwicklern nicht primär um "Perfektionismus", sondern um den erhalt der Wartbarkeit.

Fragt sich halt auf welcher Ebene man von Wartbarkeit spricht. Solange es um grundlegende Designentscheidungen geht, klar, die müssen passen.

Je mehr wir aber ins Detail, in Dinge die nur lokale Auswirkungen haben, kommen, desto besser sollten meiner Meinung nach die Gründe sein, bevor man von jemandem erwartet sie nochmal über den Haufen zu werfen, obwohl es funktional eigentlich kein Problem gibt, sondern nur das Problem "jemand anderes hätte das anders gelöst".

Zitat:Nahezu allle bisherigen Patchpacks sind irgendwann unter der Last ihrer (zumeist unfertigen, qualitativ minderwertigen) Patches zusammengebrochen. Wenn der Entwickler selber schon kaum hinterherkommt, die im Laufe der Zeit aufkommenden Inkompatibilitäten zu behandeln,

Ich habe diese Patchpacks nie im Detail verfolgt, mag sein dass da tatsächlich manches qualitativ minderwertige dabei war und ist.

Aber: Solange etwas im Status "Patch" ist, bedeutet das dass Änderungen in trunk eben nicht darauf abgestimmt werden. Die unausgesprochene Erwartungshaltung ist dann einfach, dass die Leute schon fünf, oder noch mehr Jahre lang ihre Patches immer wieder nachziehen. Und dann steht man da mit seinem auf Basis einer mittlerweile umgebauten Widget-Basisklasse entwickelten Widget, wo man dann selber rausfinden darf durch was man das ersetzen muss - derjenige der in trunk die zehn Vorkommen ersetzt hat konnte das praktisch in Fließbandarbeit machen, im Patch wird sowas zur größeren Detektivarbeit.

Und wenn das dann nicht nur ein einzelnes Patch ist, sondern ein ganzes Repository voll davon, wundert mich das wenig dass das irgendwann zum Problem wird. Man kann einfach nicht endlos lange beliebig viel Code in Patches verwalten.

Deswegen sollte man alles daran setzen die Zeitspanne wo etwas als Patch lebt kurz zu halten...

Zitat:Deswegen ist der Patch-Review-Prozess so konservativ angelegt.

... und dazu würde eben ein Prozess *mit* (frühzeitiger) Kommunikation gehören. Ein Prozess bei dem halbwegs frühzeitig klar ist, was für trunk interessant (aber noch nicht reif genug) ist, und was sowieso nicht reinpasst [und wenn es genügend viel aus einer Spielstil-Ecke gibt was aus inhaltlichen Gründen in letzterer Ecke landet ist es vielleicht tatsächlich Zeit für einen entsprechenden fork].

Bezogen auf die mittlerweile in trunk befindlichen More Heightlevels hätte das z.B. heißen können, nicht nach 6 Jahren (ohne initiale Frage "hast du in den nächsten Monaten Zeit ein Review zu verarbeiten?" ==> "hatte ich nur begrenzt, weswegen dann natürlich ein Punkt bei mir unterging und nochmal zum großen Knall führte) das Review anzufangen, sondern bereits nach einem Jahr, wo der Hauptteil der Entwicklungsarbeit wohl schon getan war mal den Satz "Wir hätten gerne More Heightlevels in trunk, kannst du uns das in einen Zustand bringen der akzeptabel ist?" über sich zu bringen.

Bei meinen anderen beiden Groß-Patches kann ich bei den Fahrplänen nur vermuten dass die Änderung in der Funktionsweise von Fahrplänen wohl zu tiefgreifend ist als dass das jemand anfassen wollte, und bei den Flüssen ist der Code lokal im Generator konzentriert (abgesehen von Anpassungsarbeiten an der Generator-GUI keine Wechselwirkungen mit dem restlichen Spiel), aber eben mehrere tausend Zeilen Algorithmen, was bei einem Review wohl im "ich hätte den aber anders implementiert"-Feedback enden würde.

Aber wissen was die projektseitige Meinung dazu ist tue ich eigentlich überhaupt nichts, und das ist, gegeben dass das grundsätzliche Konzept seit langem stabil ist, da etliche Monate Arbeit drinstecken, und technische Probleme (abseits der Grundsatzfrage "wollen wir das Konzept?") wenn dann im Detail liegen schon arg wenig an Kommunikation. Das schreibe ich jetzt einfach mal so, wie andere Leute Patches bewerten.

Und mittlerweile schreibe ich das eben in einer Situation wo ich wenig Zeit für sowas habe (also mir eigentlich mindestens kurzfristig garnicht wünschen kann dass jemand sagt "wollen wir"), aber es andererseits auch schade finde dass soviel Arbeit in einem 95-Prozent-fertig-Zustand verpufft.

Zitat:Einerseits um sicherzustellen, daß der Patch "fertig" ist, und von Leuten, die nicht an der Entwicklung beteiligt gewesen sind, gewartet werden kann, und zweitens, um zukünftige Entwicklungen nicht zu verbauen, insbesondere wenn der Autor schon längst die Community verlassen hat.

... Teamarbeit kann aber auch sein, in solchen Fällen auf der Arbeit aufzubauen, anstatt die nächste Generation das Rad nochmal neu erfinden zu lassen - wenn man in Fällen wo man sagt "ist zwar nicht perfekt, aber groß andere Dinge kaputt machen kann es eigentlich auch nicht" sagt "passt schon" anstatt auf Perfektionismus zu setzen, eröffnet man anderen Leuten die Chance, die paar Ecken die eine Neuentwicklung vielleicht noch hat über ein paar kleinere Patches auszubügeln.