Komplexität

Volker Grabsch vog at notjusthosting.com
Mo Jun 20 12:24:19 UTC 2011


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
---<<(())>>---



Mehr Informationen über die Mailingliste FSFE-de