Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo *, 2013/9/27 Thorben Thuermer r...@constancy.org - schnellere Bearbeitung von requests ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet werden/sein sollten. Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne commit, sondern auch ohne Test- weil's einfach niemanden interessiert. das ist aber kein problem des maintainers, sondern der community. da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei mir zB., alles selbst zu testen. Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer. Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne ist da/wenn die Maintainer keine Kommentare abgeben. Und um hier aktiv etwas beizutragen: ich habe immer noch einen Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin- die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen... ich wollte schonmal dazu sagen: was genau hindert dich daran, den test-code zu commiten und einen pull-request zu stellen? das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein (wenig?) vorhandener code veraendert wird. Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die Bits setzen langsam Staub an. Für mich als Contributer demotivierend... ... denke nicht, siehe community-problem. siehe auch der naechste punkt. (auch sprach ich von pull-requests, die manchmal reinkommen ohne dass es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) ) Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die git Notifications auch and die Entwickler-ML? Im Moment bleibe ich bei meiner Einschätzung- VZ ist von Entwicklerseite sehr schwer zugänglich. Voraussetzung für den Aufbau einer entsprechenden Community ist aus meiner Sicht mehr Agilität. vg Andreas
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
On Tue, 12 Nov 2013 10:05:59 +0100 Andreas Goetz cpui...@gmail.com wrote: 2013/9/27 Thorben Thuermer r...@constancy.org - schnellere Bearbeitung von requests ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet werden/sein sollten. Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne commit, sondern auch ohne Test- weil's einfach niemanden interessiert. das ist aber kein problem des maintainers, sondern der community. da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei mir zB., alles selbst zu testen. Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer. Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne ist da/wenn die Maintainer keine Kommentare abgeben. hatte ich ja... wollte gerade einen neuen schreiben, als deine mail kam. neuer kommentar: schick wieviel da aufeinmal passiert... magst du dich erstmal mit robert absprechen, wessen loesung jetzt besser ist, zumal ihr ja anscheinend an den gleichen sachen arbeitet, und die patches vermutlich nicht kompatibel sind? Und um hier aktiv etwas beizutragen: ich habe immer noch einen Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin- die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen... ich wollte schonmal dazu sagen: was genau hindert dich daran, den test-code zu commiten und einen pull-request zu stellen? das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein (wenig?) vorhandener code veraendert wird. Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die Bits setzen langsam Staub an. Für mich als Contributer demotivierend... ja, hangt bei mir daran, dass ich das nochmal testen wollte (die erste version war ja nun eindeutig kaputt ;) ), und nicht soviel zeit habe momentan. (und die dann noch mit dem lesen von -users verschwende...) (und ausserdem ich persoenlich composer nicht mag, und nicht soviele argumente dafuer kamen... (ausser dass travis-ci das braucht) aber mir soll's recht sein, hatte das auch gerade mit justin angesprochen, was er davon haelt.) aber wie gehabt, testen koennte das aber auch jeder andere mal, und feedback geben ob's bei ihm funktioniert! dafuer braucht man keine commit-rechte. (wuerde vlt. helfen wenn die github-kommentare auch an die -dev liste gehen wuerden, justin, kann man das einrichten?) ... denke nicht, siehe community-problem. siehe auch der naechste punkt. (auch sprach ich von pull-requests, die manchmal reinkommen ohne dass es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) ) Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die git Notifications auch and die Entwickler-ML? hatte den satz oben gerade geschrieben, bevor ich deinen gelesen hatte ;) dass die notifications da momentan nicht hingehen solltest du sehen, da du ja auf der liste bist. Im Moment bleibe ich bei meiner Einschätzung- VZ ist von Entwicklerseite sehr schwer zugänglich. Voraussetzung für den Aufbau einer entsprechenden Community ist aus meiner Sicht mehr Agilität. vg Andreas - Thorben
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo Justin, Composer ist ein Werkzeug um Abhängigkeiten bei PHP-Projekten zu verwalten. Du schreibst in eine Datei (composer.json) welche Bibliotheken Du in welchen Versionen haben möchtest (optional *) und rufst Composer auf. Das Tool installiert dann in einen Ordner vendor/ alle angegebenen Bibliotheken und falls nötig deren Abhängigkeiten. Composer stellt einen Autoloader zur Verfügung, so dass im Projekt nur noch require 'vendor/autload.php' stehen muss und alles steht zur Verfügung. Die zur Verfügung stehenden Bibliotheken sind alle hier registriert: http://packagist.org/, gehostet werden sie in der Regel auf Github. Bei der Installation der Sachen kann zwischen Entwickler und Anwender unterschieden werden, so dass beispielsweise ersterer PHPUnit oder Debugging-Tools zusätzlich installiert bekommt und letzterer nicht. Im Prinzip funktioniert Composer wie PEAR, nur projektspezifisch. Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md Vorteile: * vereinfachte Installation von Abhängigkeiten, inklusive von deren Abhängigkeiten * ein sehr gut getesteter Autoloader, der auch für den eigenen Code verwendet werden kann * 3rd-Party-Software wandert in einen eigenen Ordner im Projekt Ich möchte gerne Erweiterungen einbauen, die neue Abhängigkeiten einführen. Ohne Composer müsste ich mir ein Skript schreiben, dass die Sachen runterlädt und auspackt. Und die Anwendung müsste die einzelnen Installationsorte kennen und die jeweiligen Autoloader laden. Mit Composer beschränkt dich der Aufwand auf neue Einträge in der composer.json und den Aufruf von composer install bzw composer update. Ich glaube Composer steht bei PHP für einen Paragimenwechsel in der Programmierung. Von http://de.wikipedia.org/wiki/Not-invented-here-Syndrom geht man über zu http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants . Robert Am 12. November 2013 22:52 schrieb jus...@justinotherguy.org: Servus, Am 12.11.2013 um 20:32 schrieb Robert Ewald robert...@jtro.de: Ich kann Euch versichern, Composer ist für PHP-Projekte in jeder Hinsicht ein Fortschritt: die Installation von externen Komponenten, die Handhabung ihrer Abhängigkeiten, ihre Aktualisierung und auch die Benutzung wird extrem vereinfacht. Ein Beispiel: $ git clone -b unittests https://github.com/r3wald/volkszaehler.org.git $ cd volkszaehler.org/ $ composer update $ vendor/bin/phpunit […] Ich würde aber auch gerne mal ein paar Gegenargumente zu Composer hören. ich kenne Composer gar nicht (nein, das ist nicht das Gegenargument (c; ) - was sind die Ziele? - [vereinfachte] Tests (und damit: potenziell höhere Code-Qualität)? - vereinfachter Einstieg für neue Entwickler? (oder: wird der Einstieg damit [noch] schwieriger?) - vereinfachte Installation der Middleware für neue Nutzer? (klingt für mich nicht so, muss aber auch kein Ziel sein; die Installation sollte m.E. dadurch zumindest nicht verkompliziert werden) Gruss, J.
