Markus Kaemmerer <[EMAIL PROTECTED]> wrote on 23.10.04:
> [EMAIL PROTECTED] (Stefan 'Steve' Tell) wrote:,
>>> Man k�nnte mit dem Source und der Erfahrung von OpenXP (vorerst
>>> zumindest nur Teile von) FreeXP auf 32 Bit portieren und damit
>>> nutzbar machen.
>> Wer soll das denn tun? OpenXP hat eine seit Jahren offene Bugliste
>> mit einigen echten Hauern drin, selbst da geht keiner ran. Es fehlt
>> nach wie vor an Manpower und die wird auch dadurch nicht mehr, dass
>> man mehr Source zum Portieren ranschafft.
> die wenigen Ressourcen wurden ja getrennt und bei FreeXP ist quasi
> Michael Heydekamp der Herrscher �ber alles, entweder er tut es oder am
> Ende keiner.
Martin und Joachim haben eine Menge Dinge getan, zu denen ich weder
gekommen w�re noch die ich -- selbst bei einem besser ausgestatteten
Zeitkonto -- h�tte tun k�nnen.
Stefan ist im Hintergrund st�ndig als Ansprechpartner parat und hilft
auf Anfrage bei jedem Problem. Dasselbe gilt f�r Jochen.
Und wenn einen der beiden mal der Hafer sticht, dann hat die
Vergangenheit gezeigt, da� sie pl�tzlich auch zu einem Rundumschlag
ausholen k�nnen, der der Userschaft mal wieder zu einem Knaller-Feature
verhilft.
Was ich mache, ist im Moment und seit l�ngerem leider die frickelige
Detailarbeit an den komplizierten Routinen, an die man ungerne rangeht
(Stichwort 'DoSend'), die nicht wirklich Spa� macht und auch optisch
nicht viel hergibt, gleichwohl aber auch getan werden mu�.
> So kommt man nat�rlich nicht weiter. Man kann halt nicht alles selbst,
> perfekt und auf dem umst�ndlichsten Wege (16 Bit) tun. Wenn man das
> doch will, kommt man nie zu einem Release, wie wir hier sehen.
Ich wei� immer nicht, was das mit einem Release zu tun hat. Man k�nnte
eine Doku fertigstellen und unmittelbar danach der existierenden FreeXP-
Version das Etikett "Release" anheften.
Das w�rde zwar nicht unbedingt meinen Anspr�chen an ein Release gen�gen,
aber es w�rde ganz sicher den Anspr�chen gen�gen, die an bisherige
XP-Releases gestellt wurden.
> Man k�nnte ja auch die Arbeit etwas aufteilen. MH macht den UUZ, ich
> den externen Client, MW kann da mitmachen und/oder der Rest kann sich
> um das eigentliche Hauptprogramm k�mmern,
Das ist alles viel zu vereinfacht dargestellt. Wenn's nur der UUZ w�re,
an dem ich arbeiten m��te, dann h�tte ich so gut wie kein Problem.
Hier liegt allerdings kilometerweise halb- bis dreiviertelfertiger Code
aus dem Hauptprogramm (speziell xp4*/xp6*) herum, der erstmal
fertiggestellt werden mu�.
Auch das habe ich schon recht oft gesagt. Dieser Umstand blockiert
leider etwas die Arbeit am "Hauptprogramm".
> Wie w�re es mit einem Projekt, welches alle Mitarbeiter und das beste
> aus den jeweils vorhandenen Projekten (FreeXP, OpenXP und XP2, evtl.
> noch die �lteren Derivate) nimmt und kombiniert?
Genau das ist FreeXP doch bereits:
----------8<----------
| FreeXP ist kein "Team" und kein "Projekt" im �blichen Sinne, sondern
| versteht sich als lose und projekt�bergreifende Kooperation einzelner
^^^^^^^^^^^^^^^^^^^^
| XP-Entwickler und weiterer Mitwirkender. Ziel ist u.a., durch die
| Losl�sung von der strikten Bindung an eine bestimmte Organisationsform
| die Zusammenarbeit auch mit "fremden" Entwicklern zu erleichtern und
| damit Ressourcen zu b�ndeln und zu optimieren.
|
| Letztendlich sollen alle XP-Versionen davon profitieren, f�r FreeXP
| selbst ist es eine wesentliche Grundlage, das bereits erreichte Niveau
| hinsichtlich Bedienbarkeit, Funktionalit�t, Bugfreiheit und
| Userakzeptanz weiter zu verbessern.
----------8<----------
Steht seit jeher so auf der Website.
Nach Fertigstellung der eigenen Baustellen wird von XP2 -- in etwas
verbesserter und modifizierter, aber 100%ig kompatibler Form -- HdrOnly
und MsgID-Request �bernommen. Inzwischen habe ich mit Zustimmung des
XP2-Teams genau aus diesem Grund auch Zugriff aus das CVS-Repository von
XP2, weil's mit simplem Reinkn�ppeln nicht getan sein wird und man ja
auch mal sehen will, was im Laufe der Entwicklung alles wie und warum
gefixt und erweitert wurde.
Danach ist FreeXP von der Gesamtfunktionalit�t her sowieso die
attraktivste XP-Version (ist es eigentlich jetzt schon, aber manche User
m�ssen wegen dieser beiden Punkte halt noch XP2 einsetzen).
Dann kommen endlich die anderen Dinge dran, die schon lange auf der
Agenda stehen. Inwieweit man da von OpenXP Designideen �bernehmen kann,
mu� man mal sehen, aber bisher habe ich Dinge lieber selbst entwickelt
als Code einfach zu �bernehmen, zumal der von OpenXP i.d.R. ja ohnehin
nicht "as is" �bernommen werden kann.
Nachdem ich z.B. gesehen habe, woraus die seit langem auf der OpenXP-
Website angepriesene mbox-Unterst�tzung im UUZ wirklich besteht und wie
sie arbeitet (bzw. eben nicht arbeitet), hat das meine Meinung �ber
OpenXP insgesamt mal wieder best�tigt. Und ja, ich wei�, da� Du damit
nix zu tun hast, u.a. deshalb habe ich dieses Beispiel gew�hlt (prim�r
aber, weil's einfach das letzte mir erinnerliche Beispiel f�r schlampige
Implementierung war).
Anyway, wenn jemand meint, eine gute sowie sorgf�ltig und korrekt
umgesetzte Idee von OpenXP nach FreeXP �bernehmen zu m�ssen, kann er das
ja auch jetzt schon tun, sofern der urspr�ngliche Entwickler zustimmt,
da� der Code (auch) unter SLizenz gestellt werden kann. Anderenfalls
mu� er den Code halt selber schreiben.
> Ich w�rde den externen Client (und nur den) machen und mich aus dem
> Rest raushalten. MH k�nnte den UUZ machen und aus dem Rest raushalten.
Sehr witzig -- und wovon tr�umst Du nachts?
Ich werde sicher nicht mehrere hundert Stunden Arbeit in die Tonne
treten, die anschlie�end dann ja jemand anderer wieder nachholen m��te,
um m�glichst zum selben Ergebnis zu kommen.
> Du k�nntest dich um die Unixoiden Portierungen k�mmern usw... Schon
> w�ren sogar die 'politischen' Probleme halbwegs gel�st
Ich sehe bei FreeXP keine "politischen" Probleme, weil es sich anders
definiert (siehe oben).
Als Jochen von jgXP auf FreeXP gewechselt ist, hat er ohne gro�e Worte
ein paar Codeschnipsel f�r Dinge reingereicht, die er gerne ge�ndert
h�tte. So einfach kann das sein. Ein Teil davon wird implementiert
werden, ein anderer nicht. Das patcht er sich zur Not dann jeweils
selbst rein, ohne das gleich als eigenen Zweig zu deklarieren.
> und es ginge wieder um den User und ein Programm, das er auch in
> Zukunft noch vern�nftig nutzen kann.
Darum geht's hier sowieso die ganze Zeit. Ich denke, das merken die
User auch -- z.B. an der Qualit�t des Supports.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
