Joachim Merkel <[EMAIL PROTECTED]> wrote on 28.06.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>>> 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.
> Gerade hast Du noch geschrieben, da� viele Sachen von Dir nicht
> commitet werden, die nicht ausreichend dokumentiert sind.
Nah - wo hast Du das denn gelesen? Nicht die Dokumentation ist
unvollst�ndig und l�ckenhaft, sondern der Code selbst. W�rde es nur an
ein paar erl�uternden Zeilen f�r SNAPSHOT.TXT fehlen, h�tte ich die
l�ngst geschrieben und das Zeug w�re im CVS.
> Das hei�t IMO, selbst wenn sie es w�ren, st�nde Dir noch eine
> Diskussion bevor.
Vielleicht ja, vielleicht nicht. Aber das ist doch v�llig unabh�ngig
davon, wie lange sich die Entwicklung jeweils hingezogen hat.
Wenn jemand in der Lage w�re, das ganze Ger�mpel in einem Tag
fertigzustellen und zu dokumentieren, w�rde er es also am Ende des Tages
committen. Es w�rde sich aber danach exakt derselbe Diskussionsbedarf
(der auch null sein kann) ergeben.
Ich w��te auch nicht, was es z.B. daran zu diskutieren g�be, wenn man
den Bug behebt, da� Cc-Mails oder X-Postings unter bestimmten
Bedingungen immer noch in mehrere Einzelnachrichten auseinander-
dividiert werden. Da freut und bedankt man sich (oder nimmt
kommentarlos zur Kenntnis), da� das jetzt nicht mehr so ist und gut ist.
Da, wo Diskussionsbedarf von vorneherein gegeben und erkennbar ist (z.B.
bei Designfragen), habe ich es auch in der Vergangenheit schon so
gehalten, da� ich die Diskussion selbst ansto�e.
> Entweder wird man also vermeiden �ber diskutieren zu wollen, auch weil
> es nicht ausreichend dokumentiert ist
Der Fall wird - wie schon bisher - nicht eintreten. Es wird (mehr als)
ausreichend dokumentiert sein.
> oder aber auch bei mir gibt es z.B. Workarounds, wo fertige L�sungen
> noch nicht ausdiskutiert werden k�nnen. Ich habe einige �nderungen f�r
> das verbesserte Handling zum Verschieben und nachtr�glichen Bearbeiten
> von Brettnachrichten und vermutlich komme ich auf �ber ein halbes
> Dutzend solcher �nderungen die nicht "bis zu Ende" programmiert sind.
Na eben, und die sehe ich auch nicht und will sie auch gar nicht sehen,
solange Du sie nicht selbst als "bis zu Ende" programmiert betrachtest -
es sei denn, man wird um Hilfe bei konkreten Problemen gebeten, weil
derjenige irgendwo festh�ngt.
Letzteres ist aber gar nicht mein Problem, sondern hier geht es um ein
reines Zeitproblem, n�mlich das Mi�verh�ltnis zwischen dem aufgrund der
Komplexit�t der �nderungen und der Menge der anstehenden Arbeiten
insgesamt zwingend notwendigen Zeitaufwand und der zur Verf�gung
stehenden Zeit.
Falls Deine nicht "zu Ende" programmierten Workarounds von vorneherein
darauf angelegt sind, eine Art Temp-Fixes f�r eigene Zwecke zu sein, ist
das allerdings etwas anderes und nicht mit den �nderungen vergleichbar,
�ber die ich spreche und an denen ich arbeite.
> Wenn es jemand �bernehmen will, von mir aus. Ich wundere mich einfach
> nur, da� es nach Jahren CVS keinen Bedarf an solchen Zwischenstufen
> gibt, sondern die Sachen stur bis "zu Ende" entwickelt werden.
Es w�rde mich noch mehr Zeit kosten, a) die Sachen in regelm��igen
Abst�nden aufdr�seln zu m�ssen, um sie �berhaupt sinnvoll und f�r Dritte
nachvollziehbar committen zu k�nnen, und b) an Diskussionen �ber L�cken
und Bugs teilnehmen zu m�ssen, die ich eh schon kenne und an denen ich
noch arbeite.
Der Code mu� ein bestimmtes Stadium erreicht haben, um �berhaupt eine
sinnvolle Diskussion f�hren zu k�nnen, und das hat er nach meinen
Ma�st�ben noch nicht.
Zumindest m�chte ich den Code soweit bereinigt haben und wieder
durchblicken, da� ich an einer etwaigen Diskussion dar�ber auch
teilnehmen kann. ;)
> Wobei ich durchaus nachvollziehen kann, da� eine Grenze gesetzt wird,
> die im konkreten Fall f�r eine Version definiert werden soll.
Gut, aber dann verstehe ich das hier nicht:
> Wenn man keine Einblicke in seine "Werkstatt" gibt, wird man auch
> keinen dazu motivieren mitzumachen.
Nehmen wir an, Du arbeitest z.B. an dem Verschieben von Nachrichten in
andere Bretter. Da w�re es mir viel lieber, Du wartest am Tag X mit
einer funktionierenden L�sung auf, statt �ber einen l�ngeren Zeitraum
halbfertiges Zeug zu committen, das nur teilweise funktioniert und mit
dem ich mich eh nicht n�her besch�ftigen kann.
Vor allem w��te ich �berhaupt nicht, weshalb es mich weniger motivieren
sollte, meine eigene Arbeit in einem v�llig anderen Bereich
fertigzustellen, nur weil ich Dir bei Deiner Arbeit nicht st�ndig �ber
die Schulter gucken konnte.
Und auch hier nochmal das Beispiel: Bei dem Super-Duper-Entwickler, der
es z.B. schafft, Reply-To-All oder Euro-Support mit allem Drum und Dran
an einem Tag zu programmieren, hast Du zwangsl�ufig auch nie einen
Zwischenstand gesehen, sondern nur das fertige Ergebnis am Ende des
Tages. Wo genau ist das Problem und weshalb stellt sich das bei einer
l�ngeren Entwicklungsphase grunds�tzlich anders dar?
> Der andere Fall ist die wundersame Vermehrung der Aufgaben, die sich
> aus einer ungeahnten Anforderung beim Ausbau eines kleinen Bugs
> ergeben ist eher dem Bereich Gesamtkosten und Lifetime-Maintenance
> zuzuordnen.
Wo immer man das zuordnet, gemacht werden mu� es und Zeit kostet es
auch. Insofern besch�ftigt mich die Frage der Zuordnung weniger.
> Insofern kann man sicher das Thema hin- und herw�lzen und teilweise
> nur oder noch von tr�umen, wie jha von substanziellen Fortschritten,
> so z.B. das Beschleunigen beim Einlesen von Nachrichten in die
> Datenbank. ;)
Da sehe ich angesichts der Hardware-Entwicklung eher weniger Bedarf und
bin auch nicht sehr zuversichtlich, da� man da �berhaupt viel machen
kann. Das sind Aktionen f�r Zeiten, in denen man Langeweile hat, aber
der Fall d�rfte in den n�chsten Jahren hier jedenfalls kaum eintreten.
> BTW ist nicht damit zu rechnen, da� KHW mal eine 1:1 Source-Version
> von UKA_PPP 1.72 auf dem FreeXP-CVS legen m�chte? Sollten wir ihn
> darauf hin mal anschreiben?
Was genau w�re die Frage? Aufs CVS legen k�nnten wir das doch besser
selbst - geht's Dir darum, die Sourcen �berhaupt erstmal vollst�ndig und
in aktueller Fassung zu haben?
AFAIK m��te sich KHW die genauso von seinem chaotischen FTP-Server
zusammenklauben wie wir das auch tun k�nnten. Klar kann man ihn mal
fragen, aber ich kann Dir jetzt schon sagen, da� er nix dagegen haben
wird. ;)
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
