Eine kritische Betrachtung der neu gegründeten PEAR Group

Neue Birnen braucht das Land
Kommentare

Am 9. Mai 2003 fand am Rande der vom Software und Support Verlag ausgerichteten International PHP Conference in Amsterdam auch ein von Lukas Smith initiiertes PEAR-Meeting statt. Als ein Ergebnis dieses Treffens gab Stig S. Bakken, der Vater des PEAR-Projektes, am 12. August 2003 die Gündung der PEAR Group [1] bekannt. Diese hat zur Aufgabe, sich zukünftig um die Verwaltungsbelange von PEAR (PHP Extension and Application Repository) zu kümmern. Seit dieser Ankündigung ist inzwischen ein gutes halbes Jahr ins Land gegangen und wir werden nun einmal schauen, ob bisher mehr als nur Vorsätze entstanden sind.

Als Gründungsmitglieder werden neben Stig auch Lukas Smith (MDB), Pierre-Alain Joye (pearfr.org, GD-Extension), Martin Jansen (dclp*-FAQ, PEAR-Dokumentation und -Administration), Jesus M. Castagnetto (diverse Math-Pakete), Alan Knowles (Midgard, phpmole-IDE, php-gtk, bcompiler), Tomas V. V. Cox (DB, diverse XML-Pakete) und Jon Parise (Horde-Projekt) benannt. Diese acht Mitglieder haben sich neben den genannten Projekten auch allgemein um die Verbreitung von PEAR verdient gemacht und sind alle gleichberechtigt.

Beschlüsse und Mitgliedschaft

Diese Gleichstellung sowie die Mitgliedschaft in der PEAR Group sind im ersten Beschluss vom 20. August 2003 (siehe [2]) festgelegt. Dieser beschreibt den Ablauf eines Abstimmungsverfahrens wie folgt:

  • jedes Mitglied kann mit yes, no oder abstain (Enthaltung) stimmen
  • eine Entscheidung gilt als unentschieden, bis ein positives Abstimmungsergebnis erzielt wird
  • enthält sich mehr als die Hälfte der Mitglieder, so ist die Entscheidung ebenfalls unentschieden
  • es wird empfohlen, das Ergebnis außerhalb der PEAR Group zu anonymisieren, d.h. es wird nur die Anzahl der jeweiligen Stimmen veröffentlicht, nicht aber wer wie gestimmt hat
  • jedes Mitglied kann eine Abstimmung initiieren, benötigt aber ein weiteres Mitglied als Unterstützer, bevor es zur eigentlichen Abstimmung kommt
  • eine Abstimmungsperiode beginnt um Mitternacht (UTC) und dauert maximal vier Tage
  • stimmt ein Mitglied innerhalb dieser vier Tage nicht ab, so wird seine Stimme automatisch als Enthaltung (abstain) gewertet

Diese Regeln sind auf den ersten Blick klar formuliert, bieten aber dennoch Anlass zur Kritik. Die originale Formulierung more than half of the voting members schließt den Fall exakt die Hälfte nicht mit ein, greift in der aktuellen Konstallation der PEAR Group von acht Mitgliedern bei einem 4:4 nicht. An dieser Stelle wäre meiner Meinung nach half or more die bessere Formulierung gewesen. Des Weiteren spricht der Zusatz voting dafür, das nur die tatsächlich abgegebenen Stimmen berücksichtigt werden, nicht aber die automatisch als Enthaltung gewerteten. An dieser Stelle sollte man noch mal sprachlich nachbessern, um den Interpretationsspielraum so gering wie möglich zu halten. Weiterhin fällt auf, dass eine anonyme Bekanntgabe der Ergebnisse empfohlen wird. Nun mag man meinen, closed decisions und Open Source würden sich beißen, ich sehe das aber nicht so. Dadurch, dass hinterher niemand weiß, welches Mitglied wie abgestimmt hat, entfällt die Überlegung des Abstimmenden, ob er sich unbeliebt macht oder nicht und es werden persönliche Konflikte (ich erinnere da nur an den Metabase-Autor Manuel Lemos) vermieden. Die Länge einer Abstimmungsperiode von vier Tagen mag man als kurz betrachten, sie führt aber andererseits zu einer raschen Entscheidungsfähigkeit des Gremiums. Eine abstimmungsfreie Zeit ist zwar nicht explizit vorgesehen, lässt sich aber sicher für Fälle wie gemeinsame Abwesenheit mehrerer Mitglieder intern vereinbaren. Was ich allerdings ernsthaft vermisse, ist eine bindende Möglichkeit seitens der User, auf die PEAR Group einzuwirken. Es ist weder vorgesehen, dass per Volksentscheid eine Abstimmung initiiert werden kann, noch gibt es ein Vetorecht seitens der Nicht-Mitglieder. In der ungünstigsten Konstellation können also drei Entwickler die Belange des gesamten Projektes bestimmen, aber warten wir es ab. Die Mitgliedschaft selbst ist verhälnismäßig einfach geregelt:

  • man kann selber gehen
  • man kann von den restlichen Mitgliedern aus der Gruppe rein- oder rausgewählt werden die maximale Anzahl von Mitgliedern sollte neun nicht übersteigen

Offen bleibt, wie es zur Abstimmung über ein neues Mitglied kommt, naheliegend ist aber der Vorschlag, durch ein bestehendes Mitglied verbunden mit der Unterstützung eines Weiteren Mitglieds (siehe oben).

Neue Pakete

Eines der wohl wichtigsten Themen innerhalb des PEAR-Projektes sind die Pakete, deshalb verwundert es nicht, dass dieses Thema bereits frühzeitig, nämlich am 4. September 2003, in einem Beschluss (siehe [3]) abgehandelt wurde. Leider merkt man diesem Beschluss aber einen gewissen Zeitdruck an, aber dazu später mehr. Generell wurde beschlossen, dass zukünftige Pakete erst einen Genehmigungsprozess durchlaufen müssen, um Bestandteil von PEAR zu werden, und dass alte Pakete, die die Bedingungen nicht erfüllen, entfernt werden. Gänzlich offen bleiben dabei aber ein ungefährer Zeitplan sowie die Zuständigkeit für die Prüfung der bereits vorhandenen Pakete. Des Weiteren wurde eine Weboberfläche in Aussicht gestellt, um diesen Prozess zu vereinfachen, auch hier fehlt aber eine genaue Planung. Um ein neues Paket in PEAR einzubringen, kann jeder einen entsprechenden Antrag an die PEAR-Entwicklerliste stellen. In diesem hat der Antragsteller sein Paket zu beschreiben und mit eventuell bereits vorhandenen ähnlichen Paketen zu vergleichen. Des Weiteren hat er vorhandenen Code als Links auf .phps-Dateien zur Verfügung zu stellen und Beispiele zu veröffentlichen, wie man den Code benutzt. In Ausnahmefällen kann der Antrag aber auch ohne vorhandenen Code gestellt werden. Dies ist aus meiner Sicht insofern unlogisch, da der Abstimmung über ein neues Paket die Beurteilung des Codes vorausgehen sollte. Das Ergebnis von zu häufiger Nutzung dieser Regelung führt recht schnell zu einer Ansammlung von Projektleichen, wie sie zum Beispiel SourceForge zu Hunderten hat. Auch die Veröffentlichung von direkt einsehbaren Quellen als .phps-Dateien macht nicht sonderlich viel Sinn aus Sicht des Testers. Besser wäre aus meiner Sicht die Veröffentlichung eines gepackten Archivs zum Download. Dazu könnte man einen Bereich auf dem PEAR-Webserver zur Verfügung stellen und die eingereichten Pakete gleich durch ein Mitglied der PEAR Group hinsichtlich des Inhalts (ausschließlich PHP-Quellcode und Dokumentation) vor der Freigabe prüfen lassen. Damit verbunden könnte auch gleich der dazugehörige Antrag in ein Webformular eingegeben werden. Dadurch wäre sichergestellt, dass es nur vollständige Anträge auf die Liste schaffen und dass der Code allen ohne zusätzliche Kosten für den Antragsteller zur Verfügung steht. Ich denke dabei speziell an Leute, die keinen eigenen Webspace besitzen oder über recht geringe Traffic-Kontingente verfügen. Des Weiteren fehlt dem Beschluss eine Aussage über die Form des Codes (Verweis auf die PEAR Coding Standards) sowie die Dokumentation. An dieser Stelle ist dringend Nachbesserung erforderlich, weil ansonsten das Entfernen von regelwidrigem Code nicht erfolgen kann – es gibt nämlich keine Regeln. Ist der Antrag eingereicht, so kann er auf der PEAR-Entwicklerliste diskutiert werden. Sobald sich ein Konsens (insbesondere über den endgültigen Paketnamen) abzeichnet, kann vom Antragsteller ein call for a vote (Aufruf zur Abstimmung) eingereicht werden. Dazu muss er eine Mail an die PEAR-Entwicklerliste und die Mailingliste der PEAR Group schicken. Diese Abstimmung läuft dann eine Woche und wird anschließend ausgewertet. Stimmberechtigt ist jeder, gewertet werden aber nur die Stimmen von Inhabern eines gültigen PEAR-Web-Accounts und der Antragsteller ist ebenfalls ausgeschlossen. Abgestimmt werden kann mit +1 (dafür) oder -1 (dagegen) wobei im letzten Fall eine Begründung zwingend anzugeben ist, bei Zustimmung ist sie lediglich erwünscht. Aus der Begründung sollte klar hervorgehen, wie weit sich der Abstimmende mit dem vorliegenden Code befasst hat, sofern dieser überhaupt vorhanden ist (siehe oben). Die Abstimmungsergebnisse werden aufsummiert, das heißt, ein -1 hebt ein +1 auf. Offen ist aber, auf welcher Mailingliste abgestimmt wird, wobei eine Abstimmung auf der PEAR-Entwicklerliste (pear-dev) naheliegend ist und die Abstimmung per Webinterface ja bereits in Aussicht gestellt wurde. Aus der Summe der Begründungen pictureet sich die PEAR Group ihre Meinung und macht von ihrem Veto-Recht Gebrauch, wenn die Meinung der PEAR Group und Abstimmungsergebnis sich nicht decken. Auch wenn es nicht explizit ausformuliert ist, so gehe ich aufgrund des Kontextes davon aus, dass das Veto-Recht nur zur Ablehnung eines Paketes vorgesehen ist – auch hier würde eine präzisere Formulierung Klarheit schaffen. Später soll das noch zu pictureende PEAR-QA-Team (zuständig für Qualitätssicherung) die PEAR Group bei der Entscheidungsfindung unterstützen. Um noch etwas mehr Verwirrung zu stiften, gibt es die Möglichkeit der abhängigen Stimme (conditional vote). Diese Stimme ist an eine Bedingung gebunden und sollte nicht mitgezählt werden. Aus meiner Sicht ist diese Form der Abstimmung aber völlig fehl am Platz, denn wenn ich bestimmte Veränderungen vorschlagen will, so kann ich das auch vorher in der Diskussionsphase tun und nicht erst, wenn ein Teil der Stimmen bereits abgegeben ist. Des Weiteren soll ja diese Stimme nicht mitgezählt werden, sodass es wohl eher selten vorkommen sollte, dass jemand seine einzige Stimme an eine Bedingung bindet. Liegt ein positiver Überhang von fünf Stimmen vor, so gilt das Paket als angenommen (sofern kein Veto der PEAR Group erfolgt). Warum an dieser Stelle keine prozentuale Regelung (z.B. einfache Mehrheit, 2/3-Mehrheit) in Verbindung mit einer Mindeststimmenzahl getroffen wurde, ist mir leider völlig unklar. Eine Annahme des Paketes durch die Abstimmenden führt aber nicht zwangsläufig zur Aufnahme in PEAR, diese ist durch den Antragsteller separat bei der PEAR Group unter Berufung auf die Abstimmung einzureichen. An dieser Stelle ergibt sich der nächste Knackpunkt des Verfahrens: erst jetzt ist die Lizenz anzugeben, welche nicht explizit eingeschränkt ist. Weder kommerzielle noch mit der PHP License unverträgliche Lizenzen sind ausgeschlossen, was spätestens dann zu Problemen führt, wenn PHP zusammen mit betroffenen PEAR-Paketen ausgeliefert wird (wir erinnern uns an MySQL). Neben allen angesprochenen Mängeln bleibt zu überlegen, ob man dem Antragsteller nicht einen Betreuer zur Seite stellt, wie es bei Abstimmungen im Usenet seit Jahren üblich ist. Dieser könnte für die Einhaltung des Verfahrens sorgen und den Antrag inhaltlich hinsichtlich Formulierung und Vollständigkeit betreuen.

Versionierung

Am 14. November folgte neben den Dokumenten Forming of the PEAR Core List und Package Directory Structure auch eines namens New Guidelines for BC breaking Releases. Aus meiner Sicht ist der Name etwas unpassend gewählt, weil sich dieses Dokument (siehe [4]) primär mit der Versionierung (speziell der Hauptversionen) befasst und weniger auf Rückwärtskompatibilität eingeht. Generell wird festgelegt, dass jede Hauptversion ein eigenes Paket ist. Dies kommt dem Anwender entgegen, weil man nun getrennte Dokumentationen veröffentlichen und leichter überschaubare Abhängigkeiten formulieren kann. Um ein wenig Ordnung in die Benennung zu bringen, gibt es drei erlaubte Formen:

  • PaketHauptversion (z.B. Foo3)
  • PaketvHauptversion (z.B. Foov3)
  • Paket_vHauptversion (z.B. Foo_v3)

Bei dieser Regelung haben die Mitglieder der PEAR Group bedingt Weitblick bewiesen und eventuelle Unklarheiten von vornherein ausgeschlossen (sofern man die Regeln intelligent einsetzt und die Hauptversion größer 1 ist). So wäre aus dem Paketnamen IPv4 nicht ersichtlich, ob es sich um Version 4.x von IP oder um Version 1.x von IPv4 (im Gegensatz zu IPv6) handelt. Ein weiteres Beispiel wäre DB2, welches DB 2.x oder ein Paket für IBMs DB2 sein könnte. Die letzte Variante ist allerdings nur für den Notfall vorgesehen, weil sie sich mit der Benennung zur Abgrenzung von Verzeichnissen deckt. Offen bleibt allerdings die initiale Versionsnummer, diese könnte 0.x oder 1.x sein, sowie die Regel zur Benennung solcher Pakete. Auch das generelle Format von Versionsnummern ist hier nicht enthalten. Des Weiteren wurde festgelegt, dass der PEAR Installer zukünftig zwar auf neuere Hauptversionen hinweisen soll, diese aber nicht automatisch zu installieren hat. Dadurch bleibt man kompatibel zu Tutorials, die die Installation in der Form pear install Foo wiedergeben.

Mailinglisten

Wirft man einen Blick in das PHP-Mailinglisten-Archiv (siehe [5]), so findet man gleich neun Listen zum Thema PEAR, nämlich php.pear (stillgelegt am 15. März 2001), php.pear.bot (Entwicklung von pearbot, kein Traffic seit 26. Juli 2003), php.pear.core (neu seit 15. Dezember 2003), php.pear.cvs (die Diff-Messages vom CVS-Server), php.pear.dev, php.pear.doc (die PEAR-Dokumentation), php.pear.general, php.pear.qa (neu seit 22. Mai 2003) und php.pear.webmaster (hier sammelt sich jede Menge Spam an). Um in dieses Chaos ein wenig mehr Ordnung zu bringen, wurde eine Neuregelung der Zuständigkeiten beschlossen (siehe [6]). Zum einen gibt es die neue Liste pear-core, die sich mit allen Themen befassen soll, die das gesamte Projekt betreffen, insbesondere die Entwicklung von pearweb (die Website pear.php.net/) und dem PEAR Installer, die Qualitätssicherung innerhalb von PEAR und die Festlegung von Standards mit PEAR-Relevanz. Die Mitglieder der bestehenden pear-qa-Liste sind automatisch auch Mitglied von pear-core und die Mitglieder von php-qa und pecl-dev sind herzlich eingeladen. Des Weiteren wird darauf verwiesen, dass die PEAR-Entwicklerliste zukünftig nur noch für die eigentliche Entwicklung von Paketen zuständig ist, die Rolle von pear-doc sollte selbsterklärend sein. Offen bleibt allerdings, was zukünftig bezüglich Qualitätssicherung nach pear-qa und was nach pear-core gehört, Crosspostings sind zu erwarten. Weiterhin ist die Rolle von pear-general nicht weiter ausgeführt, ich persönlich würde eine Umbenennung in pear-user erwägen, um Kollisionen mit pear-core zu vermeiden.

Verzeichnisstruktur

Das letzte der drei Dokumente vom 14. November 2003 befasst sich mit der Vereinheitlichung der Verzeichnisstruktur im CVS und nach der Installation (siehe [7]). Für ein Paket namens Name unterhalb von Foo/Bar würde die Verzeichnisstruktur so aussehen, wie im Kasten dargestellt.

Foo_Bar_Name
 |
 +-- Name (enthält Modul.php)
 |
 +-- data
 |
 +-- docs
 |    |
 |    +-- examples
 |
 +-- misc
 |
 +-- scripts
 |
 +-- tests

Das enthaltene Verzeichnis Name ist entsprechend dem eigentlichen Paketnamen umzubenennen, für Cache_Lite hieße es also Lite. In diesem Verzeichnis befinden sich alle tiefer in der Hierarchie angeordneten Module, also zum Beispiel Foo_Bar_Name_Modul. Die beiden Verzeichnisse data und misc sind optional, weil sie für die meisten Pakete nicht benötigt werden. Dem entsprechend braucht man sie auch nicht als leere Verzeichnisse ins CVS einzufügen. Zwingend erforderlich sind jedoch die Verzeichnisse docs/example und tests. Ersteres enthält Beispielcode für die Verwendung des Paketes und ersetzt (hoffentlich temporär) die Dokumentation des Paketes. Im zweiten Verzeichnis sind Testskripte unterzubringen, deren Format zwar (vorläufig) grundsätzlich frei ist, es wird aber PHPUnit oder .phpt empfohlen. Das Packet PHPUnit selbst findet man unter [8], einen Einführungsartikel des PHPUnit-Maintainers Sebastian Bergmann sowie einen Weiteren zur allgemeinen Entwicklung von Unit Tests findet der interessierte Leser im PHP Magazin 03.2003 (Titelthema Unit Tests). Eine kurze Einführung in die Entwicklung von .phpt-Dateien findet man auf der Website des PHP-QA-Teams (siehe [9]). Der Inhalt von scripts wird bei der Installation in ein Verzeichnis kopiert, das in $PATH mit beinhaltet ist, z.B. /usr/local/bin. Wer es genau wissen will, der schaue einfach mittels pear config-get bin_dir auf seinem Rechner selber nach, unter SuSE 9.0 erhält man bin_dir=/usr/bin als Antwort. Und wohin mit dem ganzen Rest, sofern es überhaupt welchen gibt (siehe oben)? Ganz einfach, ab damit nach misc. Abschließend sei noch erwähnt, dass man seitens der PEAR Group von den Maintainern eine entsprechende Umstrukturierung ihrer Pakete erwartet, ein konkreter Termin hierfür ist aber ebenfalls nicht festgelegt.

Fazit

In den ersten Monaten der PEAR Group wurden einige wichtige Themen angefasst, aber aus meiner Sicht zu früh wieder fallen gelassen. Die vorhandenen Beschlüsse sind entweder nicht komplett zu Ende gedacht oder aber zumindest ungenau ausformuliert, andere wichtige Themen wurden bisher noch gar nicht angegangen. So fehlen zum Beispiel fixierte Regeln, wie ein PEAR-Paket zukünftig auszuschauen hat und wie es zu dokumentieren ist. Man kann sich diese Informationen zwar auf der PEAR-Website zusammensuchen, ob diese aber auch zukünftig bindend sind, bleibt (vorläufig) unklar. Des Weiteren sollte das Verfahren zum Einbringen eines neuen Paketes noch einmal überdacht werden, weil meiner Meinung nach einfach zu viele Kritikpunkte vorhanden sind. Am Ende wären konkrete Timelines noch wünschenswert, aber dazu wird es wohl vorläufig nicht kommen und solange gilt, was für PHP immer gilt: Es ist fertig, wenn es fertig ist (frei nach Rasmus Lerdorf). Auch wenn ich in diesem Artikel sehr viel gemeckert habe, sollte dennoch nicht vergessen werden, das sowohl die PEAR Group als auch die Community dahinter eine Gruppe von Freiwilligen ist, die hoffentlich auch weiterhin anwächst. Vor diesem Hintergrund wird verständlich, warum bestimmte Dinge nicht so schnell gehen, wie man selbst es gerne hätte. Abschließend hoffe ich, dass zumindest die beiden deutschen Mitglieder der PEAR Group, Lukas Smith und Martin Jansen, diesen Artikel lesen und nach gründlicher Abwägung in ihre zukünftige Arbeit innerhalb der PEAR Group einfließen lassen und freue mich schon auf den Dialog zum Thema, der zumindest mit Lukas als Quasi-Nachbar in Kürze persönlich stattfinden wird. Alle anderen können sich gerne per eMail bei mir melden.

Nachtrag

PHP ist ein schnelles Thema, es ändern sich zum Teil täglich Details. Was vorgestern noch harte Fakten waren, kann heute schon der Schnee von gestern sein und so ist es auch zum Teil mit diesem Artikel. Er war bereits fertig in der Redaktion, da änderten sich die Details und weil das Magazin noch nicht gedruckt war, will ich die Chance nutzen, auch diese Änderungen mit ins Heft zu bringen. Während im PHP Magazin 2.04 noch zu lesen war, dass sich das PEAR Proposal System (PEPr) im Testbetrieb befindet, so wurde es inzwischen von Tobias Schlitt fertiggestellt und wird inzwischen auch aktiv zur Paketabstimmung verwendet. Der interessierte Leser findet es unter pear.php.net/pepr/. Zum ersten fällt auf, dass man zur Teilnahme einen PEAR Developer Account braucht, mein Versuch den bereits vorhandenen PHP Developer Account zu nutzen, schlug fehl. Dies äußert sich lediglich darin, dass ich erneut die Login-Seite sah, eine Fehlermeldung wäre hier nett gewesen. DesWeiteren fehlt ein Hinweis darauf, wie man denn einen PEAR-Websiteaccount erhält. Üblicherweise steht das neben dem Login-Formular, zumindest sollte es aber im Handbuch stehen, bei PEAR ist beides nicht der Fall. Nach längerem Suchen fand ich den passenden Link pear.php.net/account-request.php ganz unten auf der Startseite. Nachdem diese Hürde genommen ist, kann man dann abstimmen, ein wesentliches Detail, nämlich die Lizenz, ist aber nach wie vor nicht fixer Bestandteil eines Proposals. Zum anderen ergab sich am Rande des letzten Treffens der Berliner PHP-Usergroup die Möglichkeit, mit Lukas Smith zu reden. Dabei ergaben sich einige interessante Informationen, die ich Ihnen nicht vorenthalten möchte. Die wohl wichtigste bezieht sich auf die von mir bezüglich ihrer Detailtiefe bemängelten Ankündigungen der PEAR Group. Diese werden laut Lukas so verfasst, dass der Leser bereits Kenntnisse über PEAR haben muss bzw. das mit der Ankündigung gelöste Problem bereits kennt. Zukünftig will er aber darauf achten, dass auch der PEAR-Einsteiger mit der Ankündigung alle nötigen Details erfährt (zum Beispiel in Form von Querlinks auf das Manual). Zum anderen erfuhr ich, dass der Beschluss zum Versionieren gar nicht komplett ist. Vielmehr liegt ein kompletter Antrag zur Versionierung seinerseits seit Monaten vor, über den man sich aber nicht vollständig einigen konnte, sodass nur der unstrittige Teil bisher den Schritt bis zum Beschluss durchlaufen konnte. Wäre dieser Beschluss bereits erfolgt, so wäre die Handhabung im Fall von XML_Transformer 0.9 wesentlich einfacher gewesen. Im konkreten Fall folgte auf die Version 0.8.2 (stable) eine ebenfalls als stable markierte Version 0.9. Diese benötigt aber im Unterschied zum Vorgänger XML_Util 0.5.1, was aus Sicht verschiedener PEAR-Entwickler einen Kompatibilitätsbruch darstellt. Dem entsprechend müsste die Major-Version erhöht werden, was 1.0 und eben nicht 0.9 als Versionsnummer zur Folge hätte. Des Weiteren gibt es verschiedene Ansichten darüber, was beta und was stable ist und ob es überhaupt vor Version 1.0 ein stable Release geben kann. Hier bleibt zu hoffen, dass die Vorschläge von Lukas schnell zum Beschluss kommen, um wieder ein Stück Streitpotenzial zu eliminieren. Kai Schröder ist selbstständiger Programmierer in Berlin und entwickelt seit 1993 Internet-Anwendungen. Zu PHP kam er 1999 berufsbedingt, vorher war Perl die Sprache seiner Wahl. Seine Mitarbeit am coWiki-Projekt ruht zur Zeit, Ursache hierfür sind die ständigen Änderungen innerhalb der Beta-Versionen von PHP 5. Dadurch bleibt mehr Zeit zur Beantwortung von eMail, welche Sie gerne an die Adresse k.schroeder@php.net richten können.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -