Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.06.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>> Ich k�nnte einzelne komplette Units committen, aber compilierf�hig w�
>> re das mit dem Rest-XP dann nicht. Bliebe nur, das komplette Working
>> Directory zu committen, aber dessen Zustand ist momentan definitiv zu
>> chaotisch und baustellenartig. Wir reden nicht �ber ein paar
>> �nderungen hier und da.
> Schon klar, mich wundert einfach bereits lang angefa�ten und
> halbfertigen Source zu sehen.
Was ist daran verwunderlich (mal abgesehen davon, da� Du den
halbfertigen Source ja eben nicht siehst, weil er ja nicht committet
ist)?
Solche Gro�umbauten dauern eben, und st�ndig kommen andere Dinge
dazwischen, die man "mal eben" einflechten will, bis man feststellt, da�
man sich verkalkuliert hat und es mit "mal eben" nicht getan ist.
Letztes Beispiel der UTF-8-Bugreport von HJT, von dem ich mir nicht
h�tte tr�umen lassen, da� das in einen Rewrite weiterer zentraler UUZ-
Routinen ausartet.
Da bleibt der - weniger wichtige, gleichwohl nicht weniger komplexe -
Rest halt solange liegen, bis endlich mal der 96-Stunden-Tag und die
14-Tage-Woche eingef�hrt wird. ;)
> Der CVS kann sicher auch Bereiche nach Entwicklern einrichten, die
> damit offen dokumentieren, was der Stand ihrer Arbeiten ist. Ich meine
> nicht das es unbedingt sein mu� und wenn's nicht geht, dann kann ich
> das sicher akzeptieren.
Nichts dagegen, aber der Source, �ber den ich rede, ist noch nicht in
einem Stadium, in dem er geeignet w�re, irgendetwas zu dokumentieren.
> Ich habe jedenfalls �berhaupt kein Working-Directory sondern
> -Directories
Ja klar, dito.
> Au�erdem stehen immer lange Diskussionen an, wenn Features erkl�rt
> werden. Manche solcher Diskussionen werden nie beendet.. Ich will
> keine nutzlosen Diskussionen, daher wundere ich mich, da� der CVS
> schlicht und einfach unter Wert genutzt wird.
Den Zusammenhang zwischen CVS und langen Diskussionen �ber Features
(welche genau meinst Du?) verstehe ich jetzt nicht. Bzw. inwiefern
diese Diskussionen vermieden w�rden, und warum sie vermieden werden
sollten.
>> Das Grundprinzip ist doch: Man entwickelt etwas zu Ende, dokumentiert
>> es, und committet es *dann*. Ich kenne das jedenfalls nicht anders.
> Mit "zu Ende" ist wahrscheinlich ein eindeutig abgrenzbares Ergebnis
> mit Erreichen einer definierten Zielgr��e gemeint.
Ich hatte das bereits vor l�ngerem f�r mich - kann jeder f�r sich anders
sehen - definiert: "zu Ende" hei�t, da� ich keine Bugs mehr sehe und es
so l�uft, wie ich mir das vorstelle.
Das hei�t nicht, da� eine Funktion oder ein Feature keine L�cken mehr
hat, aber das, was implementiert ist, soll m�glichst fehlerfrei laufen.
Nur die unbekannten Bugs, die ich nicht gesehen habe, d�rfen dann die
Anwender finden. Mein Bem�hen ist aber, die auf ein Minimum zu
reduzieren, dazu habe ich ja a.a.O. und mehrfach schon ausf�hrlich
Stellung genommen.
Bl�d ist nur, da� meinem Erfindungsreichtum, eigene Routinen aufs Kreuz
zu legen, offenbar weite Grenzen gesetzt sind. ;) Das erh�ht den
Zeitaufwand sowohl f�rs Testen als auch f�rs Programmieren massiv,
schl�gt sich IMO aber positiv in der Qualit�t nieder.
> Ansonst ist alles relativ, selbst die Forderung "getestet" kann man
> nicht wirklich gew�hrleisten.
Einspruch - kann man selbstverst�ndlich, wenn man das will.
Der UUZ hat Testszenarien durchlaufen, die schon l�cherlich abartig und
v�llig unrealistisch - gleichwohl RFC-konform und theoretisch denkbar -
sind. Und die *haben* Bugs zutage gef�rdert...
> Daher werden nach einer gewissen Zeit manche Versionsst�nde als
> "stable" oder sonstwie etikettiert.
Aber nach welchem Kriterium wird dieses Etikett vergeben, wenn nicht
(auch) durch eigene Tests?
Davon bringt mich gerade nach den bisherigen Erfahrungen keiner ab: Der
beste Tester ist immer noch der Entwickler selbst (unterstellt, er
befa�t sich gedanklich auch damit, was sein Code unter welchen
Bedingungen zu leisten hat und er hat ein Interesse daran, nicht nur
quick&dirty-m��ig zu Werke zu gehen).
Ich bin im UUZ �ber alten Code gefallen, da sieht man den Bug f�rmlich
vor sich, baut sich das Szenario, wo er auftreten m��te und spielt es
durch - und in der Tat tritt er (nat�rlich) auf.
Da kommt ein reiner Tester nicht drauf, und ob der Bug in der Praxis
auftritt und bemerkt wird, bleibt immer ein Zufall. Der Bug bei der
qp-Decodierung z.B., der unter bestimmten Umst�nden Leerzeichen im Body
entfernt, ist schon ewig im UUZ drin, bemerkt und bem�ngelt hat ihn noch
niemand - obwohl er nachweisbar im real life vorgekommen ist.
Nur wer guckt schon bei jedem fehlenden Leerzeichen im RFC-Puffer nach,
ob das da schon fehlte oder erst vom UUZ eliminiert wurde?
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
