RA Stehmann schrieb: > Volker Grabsch schrieb: > > > > In einem meiner Projekte (mingw-cross-env) leite ich diese Phasen > > übrigens explizit ein. Das hat den einfachen Grund, dass ich Wert > > darauf lege, dass sich an der Konsolidierung _alle_ beteiligen, > > nicht nur diejenigen, die gerade an keinen neuen Features arbeiten. [...] > Ich würde diese "Konsolidierung" einen "feature-freeze" zum Testen und > Bugfixing nennen. Scheint ein übliches Vorgehen bei der > Softwareentwicklung zu sein, sofern man nicht vorher brancht und die > Entwickler im neuen Zweig spielen lässt.
Tut mir leid, ich wollte das nicht als meine Erfindung ausgeben. Natürlich habe auch ich das nur von anderen Projekten abgeschaut. Ich wollte nur aus persönlicher Erfahrung bestätigen, dass dies tatsächlich funktioniert, und sehr sinnvoll ist. Anscheinend hat es sich aber nicht bei allen Projekten herumgesprochen. (Vielleicht ist es ab einer gewissen Projektgröße auch einfach nicht anwendbar?) Denn natürlich scheint es zunächst effizienter zu sein, einfach einen Release-Branch abzuzweigen und in Release- und Dev-Branch parallel weiter zu machen. Wenn diese Parallelität aber dazu führt, dass die Stabilisierung vernachlässigt wird, dann ist es rein psychlogisch gesehen besser, die Leute kurzzeitig einzuschränken. Denn wenn _alle_ an diesen vermeintlich langweiligen Sachen arbeiten, dann erhöht das auch die Motivation, eher an diesen Sachen etwas zu machen statt am coolen neuen Feature. Vielleicht ist das auch blauäugig von mir und hängt in Wirklichkeit einfach nur davon ab, was für Leute im Team sind. Aber ich hege die Hoffnung, dass man durch geschickte Organisation solche Pleiten von vornherein verhindern kann. Gruß Volker -- Volker Grabsch ---<<(())>>--- _______________________________________________ fsfe-de mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/fsfe-de
