Contribuer à Symfony: mon expérience

Il y a à peine plus d’un an, ma première pull request était mergée dans Symfony. Trois mois se sont écoulés entre l’ouverture de la PR et sa finalisation. Retour d’expérience.

Mon premier contact avec Symfony date de 2011 avec Symfony 1.4. Je l’ai utilisé en webagency puis en SSII et maintenant chez un éditeur, 8h par jour, depuis des années. Il était temps de contribuer.

Tout a commencé avec le slack de Symfony, un super endroit qui rapproche la communauté, via un message de Nicolas Grekas sur le #general: un lien vers une feature request.

En fait, l’issue évoque un problème de “deprecated logs” bien connu et une piste de solution technique pour le corriger. Ayant déjà rencontré ce problème, je me lance alors dans l’aventure.

Une aventure (en latin adventura) est une suite de péripéties et de rebondissements […]; il peut également s’agir d’un événement fortuit, de caractère singulier ou surprenant, qui concerne une ou plusieurs personnes.

La première étape consiste à récupérer la dernière version de Symfony et lancer les tests sans quoi je serais incapable de déterminer si mes modifications provoquent un effet de bord non désiré. J’ai perdu ici un peu de temps à vouloir lancer les tests sans me référer à la documentation des contributions, notamment sur les tests.

Pour la seconde étape, j’ai modifié le projet Démo Symfony pour obtenir une configuration similaire à celle que j’essaie de résoudre. Dans le cadre de ma PR, cela consiste à avoir des deprecated pendant la construction du container, et ne plus les avoir ensuite. Facile!

Et ensuite, je me lance: je modifie le logger, je regarde du côté du container, du containerBuilder, du dataCollector et etc… Je cherche, j’itère. Je trouve des solutions puis découvre de nouveaux problèmes, ça avance et parfois ça recule. Quand finalement j’ai une solution, je nettoie mon code, refactorise ce qui peux l’être et supprime mon code de debug. Les tests passent de nouveau, en avant pour les ultimes modifications avant la PR.

Et là c’est le doute… Comment j’appelle cette variable. Est-ce que cette méthode est pas trop longue, est ce que je n’aurais pas dû créer une classe dédié à ce traitement, comment je l’appelle, je la met où? Puis au bout d’un certain temps, non sans stress, je soumets ma PR sur Github et c’est parti!

Quelqu’un vient de répondre à ma PR!

Au bout de seulement dix minutes, je me fais “Stofer”. Une pratique courante quand on se frotte aux issues et PR de symfony/symfony. En fait, c’est pas du tout évident de s’en rendre compte au premier abord, mais c’est une des meilleurs parties de la contribution à Symfony. Si si! Chaque commentaire me fait percuter que j’ai raté ou que je suis passé à côté de quelque chose. Une interdépendance tacite entre composants. Le fait que les coding standards de Symfony sont plus poussés que la PSR-2. Peut être un choix de nom de variable discutable, une probable BCBreak, un souci d’architecture, voir de sécurité…

C’est le moment où l’open source te bouscule, le moment où tu réalises que chaque classe non finale peut être étendue par un développeur quelque part, et qu’il n’aimerait pas que tu casses son projet avec ta PR. Le moment où tu te rends compte que quelqu’un a peut-être ajouté son propre DataLogger au WebProfiler, et que du coup tu n’as pas la moindre idée de ce que tu t’apprêtes à serializer. Alors tu re-découvres le code de Symfony, et tu perçois des subtilités qui permettent tantôt d’étendre ses capacités, tantôt de les préserver.

Sur le moment, on est un peu désemparé. D’autant plus que sur une feature request il y a toujours matière à interprétation et faire le moindre choix sur un projet autant utilisé peut causer quelques sueurs froides.

Et c’est là que le Slack de Symfony est vraiment très pratique: il permet de très facilement entrer en contact avec les “core-contributors”. C’est d’ailleurs ainsi que j’ai pu échanger et revoir la pull request. Chaque échange m’a permis d’itérer en affinant l’implémentation de la feature dans Symfony. L’essentiel des échanges s’est fait avec Nicolas Grekas qui gère de front presque toutes les issues et PR du repos. A plusieurs reprises il a su débloquer la situation, que ce soit prendre des choix fonctionnels ou débloquer des contraintes techniques.

Nicolas aurait pu réaliser cette PR en quelques minutes à lui tout seul, alors je me suis demandé pourquoi laisser la main à un nouveau contributeur? Aujourd’hui j’en ai compris que c’est un investissement dans la communauté.

Et puis c’est le final, l’ultime message de Fabpot pour remercier les participants, et hop! C’est mergé! Quelle fierté! Et comme c’était une nouvelle feature “conséquente”, Javier Eguiluz en a créé un “New in Symfony 3.3”. Merci Javier!

Avec un peu de recul, cette expérience me fut vraiment bénéfique pour plusieurs raisons:

1. D’abord je me suis vraiment approprié Symfony, et au quotidien, quand dans certaines situations l’utilisation du framework me parait améliorable, je n’hésite plus à me lancer et à créer une ou deux PR.
2. Puis je suis monté en compétences: sur les composants sur lesquels j’ai travaillé, sur Symfony et sur PHP. J’ai découvert énormément de choses (techniques/pratiques) en peu de temps. Sortir de sa zone de confort et échanger avec les “monstres” de la profession, est un sacré coup de boost.
3. Je passe aussi plus de temps à regarder les issues de Symfony/Symfony pour découvrir ce qui ce passe avant la communication officielle. Les PR font toujours l’objet d’échanges, et je vous encourage à participer (ou laisser une réaction si vous êtes trop timide). Et on y trouve les conseils des “core contributors” auprès des autres contributeurs, qui sont toujours d’excellentes lectures.

Voilà, j’espère que ce post vous aura donné envie de participer et contribuer à Symfony si vous ne l’avez pas encore fait.

Je tiens spécialement à remercier Nicolas Grekas, Christophe Coevoet, Javier Eguiluz et bien sûr Fabien Potencier.