Code Management

[sojo]

Prima das ist doch ein Anfang. Nur habe ich keine Ahnung wie sich das jetzt weiter nutzen läßt.

Sollen die Patch-Entwickler ihre selbst erstellten (kompilierten) Simutransversionen dort zum Test anbieten?

[Wurzelgnom]

Original von sojo
...
Sollen die Patch-Entwickler ihre selbst erstellten (kompilierten) Simutransversionen dort zum Test anbieten?

genau das

Die patch-Datei und das Binary hochladen und verlinken. Das Infofeld sollte ausgefüllt werden.

Jemand anderes kann dann auch mit der patch-Datei für andere Plattformen kompilieren und das Binary hochladen.

Wie ich einen Counter umsetzen kann, schwebt mir auch schon vor. Dann erkennt jeder auch, ob ein Patch Zuspruch gefunden hat.

Anhand des Counters kann dann evtl. auch entschieden werden, ob er ins offizielle Programm übernommen wird.

Muss mir nur noch eine Archivierung des Counters überlegen. Hab da aber auch schon eine Vorstellung.

[blitzmaster]

wie ich im englischen Forum schon geschrieben habe:

Wäre es nicht einfach sinvoller, die Entwicklung dahingehend zu managen, dass wir s.g. Meilensteine setzen, also feste Definitionen von Zielen die bis zu einer bestimmten Version eingebaut werden müssen. Dann hat prissi keine Probleme mehr, dass er sich überlegen muss ob er einen Path testet bzw. einbaut, da wir sowieso nur festgelegte Ziele verfolgen. Die Ziele müssten natürlich vorher abgesprochen werden, aber ich denke, das würde sicherlich viel besser funktionieren; immerhin machen das praktisch alle Open Source oder auch Closed Source Projekte so.

Ich wäre also für einen klar definierten Ablauf von Releases:

1. Sammlung von Features
   
2. Die Features werden programmiert
   
3. Feature Freeze: Keine neuen Features werden mehr hinzugefügt, nur mehr Bugs ausgebessert
   
4. Release
   [/list=1]

[Wurzelgnom]

Es gibt bereits ausgegebene Ziele.

KI, Netzwerk

Ausserdem gibs im Programm-SVN eine Todo-Liste (todo.txt). Gut die ist teilweise in deutsch.

Die Frage ist, wer verfolgt die Ziele dann.

Zu oft haben Leute gesagt, sie machens. Danach war dann meist Funkstille. Von Ergebnissen ganz zu schweigen.

Sicher gibs dafür vielfältige Gründe. Einer dürfte der nicht mehr vorhandene Spaß sein.

Jetzt programmieren noch viele. Ich befürchte aber, das das auch wider nachlassen wird. Vor allem dann, wenn das Programmierte von niemanden angenommen/benutzt wird.

Im Moment werden die Codeänderungen gepostet. Nur mit denen können die meisten Leute nichts anfangen. Wenns zu dem Code auch eine ausführbare Datei gibt, dann ist das für die reinen Benutzer wesentlich attraktiver, einen Patch auch zu benutzen.

Eine Gefahr die jedoch besteht, sind inkompatible Spielstände.

[sojo]

Original von blitzmaster
wie ich im englischen Forum schon geschrieben habe:

Wäre es nicht einfach sinvoller, die Entwicklung dahingehend zu managen, dass wir s.g. Meilensteine setzen, also feste Definitionen von Zielen die bis zu einer bestimmten Version eingebaut werden müssen. Dann hat prissi keine Probleme mehr, dass er sich überlegen muss ob er einen Path testet bzw. einbaut, da wir sowieso nur festgelegte Ziele verfolgen. Die Ziele müssten natürlich vorher abgesprochen werden, aber ich denke, das würde sicherlich viel besser funktionieren; immerhin machen das praktisch alle Open Source oder auch Closed Source Projekte so.

Ich wäre also für einen klar definierten Ablauf von Releases:

1. Sammlung von Features
   
2. Die Features werden programmiert
   
3. Feature Freeze: Keine neuen Features werden mehr hinzugefügt, nur mehr Bugs ausgebessert
   
4. Release
   [/list=1]

Nur weil das Andere so machen muss das nicht unbedingt Der Weg sein. Ich finde es ein wenig zu eng. Ein Spiel sollte sich doch auch von selbst in eine unbestimmte Richtung entwicklen können.

Wenn plötzlich etwas da ist an das vorher keiner gedacht hat und es finden 100 Benutzer auf Anhieb gut sollte man dies doch nicht verwehren. Oder?

Original von FrankP
Eine Gefahr die jedoch besteht, sind inkompatible Spielstände.

Darauf sollte man am besten auf der Homepage in <h1 style="color: red;"> hinweisen! (Naja vielleicht ein wenig kleiner.

[wernieman]

Da die meiste Entwicklung im englishen Forum entsteht, hast es dort auch schon gepostet (und ich habe es übersehen)?

[sojo]

Original von wernieman
Da die meiste Entwicklung im englishen Forum entsteht, hast es dort auch schon gepostet (und ich habe es übersehen)?

Ich würde erstmal abwarten was prissi dazu sagt und ob er denkt das es ihm wirklich hilft.

[blitzmaster]

Frank: Dass es Ziele gibt ist mir bekannt. Aber die werden, wie du gesagt hast, einfach nicht konsequent verfolgt.

Sojo: Also um ehrlich zu sein, es ist Der Weg der bei größeren Projekten gegangen wird...
Aber abgesehen davon: So eng ist es ja auch net. Man kann ja die Features vorschlagen. Man kann ja immer noch darüber diskutieren. Aber die Programmierung würde einfach etwas gelenkter verlaufen, was, so denke ich zumindest, sicherlich prissi helfen würde.

[Wurzelgnom]

Original von blitzmaster
Frank: Dass es Ziele gibt ist mir bekannt. Aber die werden, wie du gesagt hast, einfach nicht konsequent verfolgt.
....

Woraus Schlußfolgerst Du, das sich das Ändern würde, wenn es einen klar definierten Ablauf von Releases gäbe.

Ich hatte auch schon mal eine klar definierte Liste ausgegeben.
Ergebnis, es hat sich kaum einer dazu berufen gefühlt etwas davon abzuarbeiten.

Wenn dann nach Wochen oder gar Monaten keine Reaktionen kommen, dann wird mans eh wider selber machen müssen. Oder es bleibt ewig liegen.

Für Releases gibt es 2 günstige Zeitpunkte.

November/Dezemder - freie Weinachtszeit und Winterferien
Mai/Juni - Beginn der Urlaubszeit und die Sommerferien

[prissi]

Ich glaube kaum, das Hobbyprogrammierer für Meilensteine arbeiten. So wird in kommerziellen OpenSource Projekten wie Firefox gearbeitet (wo der Kern sein Geld damit verdient). Außerdem käme ich mir ziemlich blöde vor, mir selber Meilensteine zu setzen.

Wenn jemand ne gute Idee hat, werde ich die nicht verbieten, nur weil es kein Meilenstein ist.

Und alle haben nach selbstprogrammieren von KIs geschrien, der Thread hatte ne lange Befürworterliste. Wie die Netzwerkprogrammierung auch. Beides Sachen, die einer abarbeiten könnte, ohne unbedingt nach einem Vierteljahr Simutrans das 11jährige Grundgerüst umstoßen zu wollen.