Compte rendu du zest-meeting mai 2017
L’équipe technique s’est réunie mardi dernier pour un zest-meeting, le premier depuis longtemps. Nous avons parlé du changement de DTC, des versions passées et de l’organisation du projet. Voici le compte-rendu !
La passation des DTC
Comme vous le savez peut-être, le DTC est le directeur technique de Zeste de Savoir. C’est la personne qui s’occupe de gérer le développement, de choisir les priorités et d’effectuer la plupart des mises en production. Après 11 mois et 5 versions, victor a légué son rôle à artragis. gustavi reste quant à lui toujours DTC. 
Quelques remarques de victor
Mon but était d’améliorer la partie technique existante plus que d’y ajouter des fonctionnalités. Je voulais une codebase plus propre, plus maintenable, et un processus plus solide. En deux mots : plus stable. Après beaucoup de nettoyage et de refactorisation, je considère que c’est assez réussi. Les performances ont également pris un bon coup, notamment avec l’arrivée de la v20 et du cache des templates.
Côté nouveautés et nécrologie : les tribunes libres, la recherche, le support unicode dans nos messages (emoji unicode par exemple), la mort des ZEP.
Une semaine après avoir repris ce projet, un problème chez notre hébergeur a causé une perte de données. Lisez l’article si vous avez oublié l’histoire. Je reviens là-dessus pour dire que vérifier que nos backups sont faites ET restaurables est primordial. Perdre un disque pour ensuite constater que nos backups n’ont mystérieusement plus été faites depuis 3 mois, c’est dommage.
La v22 et la v23
Comment se sont passées les 2 dernières releases (victor)
v22
La MEP s’est bien passée si je m’en souviens bien, c’était y’a longtemps
v23
Là aussi ça s’est bien passé, il y a eu quelques ennuies avec Munin en prod parce que les instructions de l’update.md n’étaient pas correctes.
En revanche la MEB a été difficile, la v23 introduisant du code qui d’après l’update.md devait être activé par le settings_prod.py et le code en question plantait intégralement ZdS. Ce n’est jamais une bonne idée d’introduire dans settings_prod.py des trucs qui sont pas dans settings.py, vu que Travis passera pas dessus. Si ça avait été fait proprement, la suite de test aurait été rouge comme un poisson et la PR introduisant ce gros bug n’aurait pas été mergée.
Remarques générales de victor
-
La raison pour laquelle la MEP se passe bien est que la prod et la beta sont ISO, et que chaque MEB est une répétition générale de la MEP.
-
Si vous trouvez une faille dans ZdS, contactez l’équipe avant toute chose. Ouvrir un ticket expliquant comment exploiter la faille, c’est dangereux. Ce qu’on fait généralement c’est qu’on patch sur la prod, puis quand c’est sécurisé on fait le hotfix.
-
Faites gaffe avec les données de la prod. Suivez bien la procédure quand vous synchronisez la prod vers la bêta. Ne faites pas de tests sur la bêta qui exposent potentiellement les données. Ne mettez pas quelqu’un dans un groupe d’administration sur la beta, il y a des données très sensibles.
-
Les serveurs ont une whitelist d’usernames, et on ne peut se logger que par clé, pas par mot de passe. Ne changez pas ça.
-
Ne venez pas avec une grosse feature pour disparaitre sitôt qu’elle est mergée. C’est très pénible quand une PR ajoute un truc compliqué mais que l’auteur disparait sitôt que c’est en prod et n’est pas disponible pour aider à réparer les bugs qui peuvent survenir.
Résumé de la marche à suivre en cas de faille de sécurité
- contacter les devs : soit par MP (artragis/gustavi)
- soit zds-tech@googlegroups.com https://zestedesavoir.com/pages/contact/
- le hotfix (patch + issue) GitHub vient après, quand ça été sécurisé en prod + beta
Quelques remarques pour le développement
Eviter de proposer de grosses fonctionnalités si vous pensez ne pas être disponible sous peu. Ou alors faire au mieux pour transmettre la connaissance.
Pour le module tutorialv2 :
- points positifs : les méthodes utilitaires sur les modèles (
in_public, etc). La doc est bonne. - point négatif : les templates (on ne sait pas forcément quel type d’objet est quel variable).
À priori, ça va de mieux en mieux.
Crainte de la part de sandhose pour le front de manière globale
- Templates mal répartis
- Beaucoup d’override
- Le CSS a sûrement été pensé « sémantique » plutôt que « composant ».
- Manque de leader côté front
Organisation et retours divers
Premièrement nous avons identifié un problème majeur : il y a besoin de plus d’engagement pour la QA car l’attente est trop longue. Ce n’est pas surprenant, la QA n’étant pas quelque chose de gratifiant. Est-ce qu’on pourrait trouver quelque chose pour motiver les gens ?
Utilisation de l’interface de projet sur GitHub
Le but est d’essayer de communiquer au mieux le développement du site tout en s’organisant. Voici les remarques des participants :
- Un peu lourd et l’interface n’est pas top. Les milestones sur GitHub sont plus facilement utilisables.
- Dashboard sur GitLab, c’est mieux.
Les Gros Travaux (majuscules obligatoires, svp 
)
- Django 1.10 : 95% d’avancement, la 1.11 sera pour plus tard (version suivante idéalement, ça devrait être plus trivial)
- Interface de rédaction du contenu (partie JS à retoucher, mais ce n’est pas bloquant). Le besoin de QA est important.
- API des forums (Anto59290).
- Interface des contenus (ça avance par blocs mais il manque quelques composants).
- Interface de merge des contenus (Anto59290)
La demande sur l’opengraph (et la pertinence des miniature) a été remise en avant durant la réunion.
zmarkdown
Ça avance pas mal. Il y a plusieurs contributeurs donc c’est cool. Scénario optimiste : cet été.
Ce qu’il reste à faire :
- faire passer tous les anciens tests Python-ZMarkdown
- quelques plugins pour textr de manière à avoir une bonne typographie
- manque les ping, grid_tables, typographie, par exemple.
- la transformation AST => latex ça se fait, mais il faut un peu de connaissance en latex.
- il nous faut un template latex qui passe par pdftex et contenant tous les éléments de nos contenus (markdown)
- => demander sur le fofo => gustavi se propose pour faire un sujet sur le forum <3 AmarOk peut aider aussi
- L’idée est donc que quelqu’un crée une feuille de style latex pour nos contenus, avec des macros/commandes latex permettant de générer nos blocks ’perso’, genre
\questionblock{mon block question}. Le but est d’avoir toutes nos features et d’avoir un beau rendu PDF. Ensuite on fera AST -> latex.
- Sandhose va travailler sur un éditeur de texte, potentiellement intéressant pour ZdS aussi.
Il faudra trier les vieilles PR/issues qui ne bougent pas.
Certaines personnes sont intéressées pour le déploiement continu (du moins en bêta). Mais le ratio effort/bénéfice est en doute. (victor : ouais amha on a de plus hautes priorités, du coup sauf si on tombe sur la personne idéale qui veut s’y mettre à fond pour une longue période, ça vaut pas vraiment le coup, concentrons-nous sur notre core business).
Il faudrait utiliser les ModelForm pour améliorer la codebase. Ça permet d’utiliser des CreateView et UpdateView, ce qui est bien (exemple) !
Les parcours : peut-être un jour, si ça passe les PR tant mieux. Courant juin, on pourrait envisager le module de vote générique : gustavi veut s’y pencher ! Comment mettre en avant les billets (ratio de votes + temps de lecture sur le billet). On peut utiliser l’algorithme de HackerNews.
Participation de la communauté
- En s’inspirant de Gnome, on pourrait faire séances de bug squashing. pas forcément sur le code.
- Une piste ici : https://zestedesavoir.com/forums/sujet/7440/organiser-un-defi-ou-sprint-premiere-contribution-au-code-de-zds/
En conclusion, le développement est en bonne progression. De gros chantiers sont en cours et nous espérons qu’ils pourront bientôt voir le jour. Si vous êtes intéressé par le développement du site, n’hésitez pas à contribuer vous aussi.
