Un Zest'Meeting

soit de passer le code entier de GitPython compatible utf8 (aujourd'hui, seul les modules qu'on utilise ont été migré) et faire une PR sur l'upstream

pourquoi? La zep 12 ne parle pas de git?

Je les confonds a chaque fois, mais je parlais de zep-08 plutôt

soit de migrer vers libgit2, qui nous rendrait compatible python3 plus vite que la musique.

Il me semble qu'il y avait un problème qui expliquait pourquoi on n'a pas encore fait ça, quelqu'un se souvient ?

Github vs JIRA vs une autre solution

Pour moi on a vraiment besoin d'une base de discussion (topic posé) avant de faire un point live là-dessus.

Tu n'avais pas commencé un topic où tu détailles "Notre mauvaise utilisation de GitHub" ? Ce serait un bon point de départ.

Il me semble qu'il y avait un problème qui expliquait pourquoi on n'a pas encore fait ça, quelqu'un se souvient ?

Il n'y a pas de binaires de libgit2 fournit dans le binding python. Donc ça suppose que pip le compile. Ça ne pose pas de soucis pour les linuxiens mais c'est plus problématique pour les windowsiens.

En gros ça supposait qu'on pré-compile libgit2 sous windows pour aider les dev sous windows (a noter que Microsoft fournit une VM pré-configuré avec Visual Studio + Python-dev dédié à ce genre de tache).

ça c'est vrai. Le gros de la discussion était sur github, mais je vais voir pour créer un topic là dessus si quelqu'un ne le fait pas avant moi.

Concernant LibGit2, le problème était sous windows, comme la expliqué dit Kje ci-dessus. Mais on peut encore reconsiderer ça tout de même car je pense qu'on gagnerai tout de même en perf en plus du fait que toutes les modification que j'ai effectué dans GitPython sont déjà intégrées dans LigGit2.

Concernant LibGit2, le problème était sous windows, comme la expliqué dit Kje ci-dessus. Mais on peut encore reconsiderer ça tout de même car je pense qu'on gagnerai tout de même en perf en plus du fait que toutes les modification que j'ai effectué dans GitPython sont déjà intégrées dans LigGit2.

C'est meme pire que ça. libgit2 et le bindings python sont développés et supportés par de grosses entreprise, tout est bien mis a jour et maintenu alors que GitPython est un projet mort. libgit2 est déjà compatible python3 alors que GitPython non. On peut aussi rajouter que maintenant Git lui même utilise libgit2 en interne pour certaines opérations.

Si des zeps doivent remettre a plat l'utilisation de git dans notre code, autant que ce soit fait. Quitte a ce qu'on fournisse une dll pré-compilé pour les windowsiens.

il me semble que powershell utilise libgit2 donc de toute façon sauf erreur de ma part, on l'a déjà cette dll.

il me semble que powershell utilise libgit2 donc de toute façon sauf erreur de ma part, on l'a déjà cette dll.

Le truc est que probablement que le binding python est écrit en C et l'integre de cette façon. C'est peut être plus ça qui doit necessité la compilation

edit: A noter que j'ai trouvé des version pré-compilé : http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygit2

Voilà qui m'a l'air intéressant.

On peut faire un topic dédié à ce point du coup ?

Rha, j'ai essayé de retrouver le topic où l'on avait discuté des solutions envisageables et je ne le trouve plus, ce devait être pendant la bêta privée…

C'est dommage, l'inventaire était dressé avec une granularité assez fine, depuis un Redmine/JIRA qui référence des issues, des PR, des commits, etc. jusqu'à la solution "full custom" avec des git hooks. en passant par (de mémoire…) d'autres outils comme HuBoard et ZenHub avait été cités également.

La discussion m'intéresse énormément, j'ai jamais trouvé LA solution idéale pour :

• découper les problématiques fonctionnelles/techniques proprement

• mais pouvoir faire l'association entre fonctionnel et techniques facilement (i.e. le problème fonctionnel est décrit dans une issue, faisant référence à des issues techniques "masquées" pour le rapporteur fonctionnel)

• s'interfacer élégamment avec un système de gestion de versions (ici git voire Github)

• minimiser au maximum les doublons (une place pour chaque chose, chaque chose à sa place)

• gérer des roadmaps, les milestones, les afficher de façon user-friendly pour le non-développeur

• gérer le multi-projet, avec parfois des liens forts entre les projets

• gérer la QA "automatiquement", i.e. un développeur ferme un ticket, il part dans les tickets à QA

• gérer un wiki collaboratif pour définir les spécifications. Pouvoir "attacher" la spec à un ou plusieurs tickets, à une milestone

En gros un espèce de dashboard de gestion de projets avec plusieurs "facettes" pré-conçues (ou paramétrables). Pour la liste ci-dessus : GitHub fait presque tout ça, Redmine aussi, JIRA sans doute également. Mais la vue multi-facettes manque cruellement.

A chaque MEP on devrait pouvoir générer automatiquement plusieurs reports :

• report technique avec les corrections de bugs (techniques), évolutions (techniques) (ici : modification du module de cours, corrections du flux RSS). A destination de suivi pour les développeurs, contributeurs.

• report "business" avec les évolutions demandées par des clients (ici les utilisateurs), l'ajout de fonctionnalités "vendeuses" (nouvelle page d'accueil, …)

• report "client-care" avec les corrections de bugs (fonctionnels) remontés par des clients "Le bug que vous avez rencontré est maintenant corrigé".

J'espère qu'on va trouver la panacée, …

C'est fait.

BILAN DU ZDS-MEETING #3

I - Toujours plus open source

1. Internationalisation

• Dans un premier temps il faudrait permettre au site d'être traduit côté front
• La discution sur le passage du front en EN ou alors le garder en FR est à faire sur les forums

2. État de la documentation

• On dégage toute la doc ce qui est old (GH et forums) sauf le README et le CONTRIBUTING et on centralise dans la doc accessible via readthedoc
• On crée un tuto pour le guide (rédaction communautaire, à part de la technique)
• Pour le front : soit elle reste comme elle est et donc on a des exemples en live, soit on la met dans la doc back et tout devient complètement abstrait, sans exemples, à moins de mettre des iframes partout (c'est lourd et ça fait 100000 fichiers de partout pour les exemples au lieu d'un seul simple à maintenir)

II - Suivi des ZEP

ZEP-3 (Eskimon)

• Il reste à faire : Doc précise pour palier aux limites techniques des fixtures, TU, et un petit bout de code
• Pour les fixtures et les média voir plus bas

ZEP-4 (Alex-D)

• Bloqué par les sujets chauds, toujours pas défini
• Pour débloquer on part sur : « on part sur l'affichage des x sujets qui viennent d'être répondus » pour permettre à la ZEP d'être débloquée, définition à revoir par la suite

ZEP-5 (Kje)

• On a préféré ne pas en parler parce que Kje n'était pas des notres ce soir

ZEP-12 (artagis)

• C'est commencé, une branche est créée mais ça casse tout
• Le modèle fonctionne
• Il faut faire un script qui migre les tutos et articles
• On a décidé de passer à libgit2 car GitPython n'est plus maintenu et libgit2 et py3k ready ! (voir ZEP-8)

III - Les outils de développement

1. Github vs JIRA vs une autre solution

• On en parle sur le forum : http://zestedesavoir.com/forums/sujet/1584/utilisons-github-de-maniere-plus-propre/

2. Les fixtures

• Pour les média : voir https://github.com/leetrout/django-fixturemedia ou https://github.com/duncaningram/django-fixture-media (Eskimon se charge de les tester avec la ZEP-3)
• Il faut refaire les fixtures pour tout le reste du site
• Ça pose problème avec ce qui utilise git, à voir une fois la ZEP-12 OK

IV - Un point rapide sur l'infra et questions diverses

• Pas de remarque particulière
• Des fois le site est lent : ça vient du VPS low cost actuel

Les sujets qui doivent être traités au prochain ZDS-meeting

• ZEP-5
• Docker

Les logs : http://paste.awesom.eu/EfEl

ZEP-4 : C'est plutot "on part sur l'affichage des x sujets qui viennent d'etre repondu" non ? (cf le sujet de la zep pour en parler)

Merci a gustavi d'avoir organisé le Zest'Meeting, je vois qu'on reste finalement sur un format d'1h, ce qui est tout à fait acceptable, sans faire perdre une soirée aux participants.

Pour le coup ce n'est pas une conclusion . Mais concernant la doc, il y'a aussi la possibilité d'étendre le css et le JS dans les templates sphinx.

ça concerne plutot la ZEP-08 et pas la ZEP-12

On a déjà un truc qui nous permet de charger des fixtures (django-factory) de manière dynamique et qu'on utilise dans tout nos tests. Y'a une raison particulière du pourquoi on ne l'utilise pas ici ?

je vois qu'on reste finalement sur un format d'1h

1h30 en fait.

On a déjà un truc qui nous permet de charger des fixtures (django-factory) de manière dynamique et qu'on utilise dans tout nos tests. Y'a une raison particulière du pourquoi on ne l'utilise pas ici ?

Personne n'a été capable pendant la réunion d'expliquer ce que tu entendais par "fixtures dynamiques".

Par contre, "avoir des médias dans les fixtures", ça répond très exactement au problème qu'on a sur la ZEP-03.

On a déjà un truc qui nous permet de charger des fixtures (django-factory) de manière dynamique et qu'on utilise dans tout nos tests. Y'a une raison particulière du pourquoi on ne l'utilise pas ici ?

C'est juste qu'on arrive pas a charger des media a partir des fixtures. (ZEP3 : https://github.com/zestedesavoir/zds-site/pull/1583 ). Si on arrive a faire ca sans nouveau truc je prend hein

Grille par spacefox

J'allais le dire. Il est possible de modifier le template utilisé par sphinx, autant niveau html, CSS que JS et il est possible dans la doc d'injecté du html. Donc pour moi techniquement rien ne l’empêche. Après effectivement il faut faire un peu de travail dessus pour le tester et vérifier que tout se comporte bien, mais dire " soit on la met dans la doc back et tout devient complètement abstrait, sans exemples, à moins de mettre des iframes partout" est une conclusion fausse et biaisé.

je ne dis pas qu'il faille absolument mettre la doc front dans sphinx, je suis ouvert a la discussion et aux arguments, mais ceux-ci en l’occurrence sont faux et malvenues.

Concernant la Zep-5, pour résumer, on a passé l'étape de validation (il a été choisi de tout passer à Pandoc) et le developpement est en cours "quand j'ai le temps".

Le plan de transition est le suivant :

• Rajouter au parseur toutes nos extensions et les vérifier en les supportant aussi dans la sortie latex/pdf.
• Mettre en place un nouveau module d'assemblage des différents extraits + metadata en entrée de Pandoc (concaténation des fichiers, ajouts des infos du manifest et de la db, décalage des titres des extraits, etc.)
• Mettre en place deux templates pour les pdf : un pour le contenu long et un pour le contenu court.
• Mettre en prod la génération des pdf (utiliser le nouveau support des pdf pour sortir une premiere version et la faire tester à la communauté par la pré-prod)
• Support de nos extensions dans les ebooks
• Utilisation de Pandoc pour le html

On en est toujours a la première étape mais celle-ci en est à environ 80%. Les deux derniers points peuvent être permutés.

Deux membres se sont portés volontaire pour me donner un coup de main (firm1 et lethom) ce qui est une bonne nouvelle pour éviter que je sois seul à maitriser cette partie de zds. Je dois leur envoyer un mp pour qu'on s'organise.

A terme un designer serait la bienvenue pour s'occuper de la partie "front" des pdf et ebook. Actuellement je bidouille les templates pour essayer de rendre un truc sympa mais j'ai des gouts de chiottes. Donc autant je peux m'occuper de gérer le template, autant ce serait bien que quelqu'un me fournisse des maquettes de rendu qu'on voudrait obtenir.

Cas d'utilisation : la ZEP-03, doit pouvoir proposer les icones d'aides (beta, etc.) dans une sorte de tableau html avec une balise <img /> par image. Chaque image doit donc être dans la base de donnée ce qui permet de rajouter/supprimer un type d'aide sans devoir refondre le design.

Problème : Quand le dev local installe ZdS en local pour travailler, s'il n'a pas dans ses fixtures ce qui lui permet de charger d'emblée les images dans la bd, il sera incapable d'apprecier la fonctionnalité out of the box. Il faudra a chaque fois charger les image à la main (en local).

Solution : faire un script qui charge des fixtures en se basant sur Django-Factory, dans le même veine que ce qui est fait pour les tests de charge mais avec des messages un peu plus réalistes. Ce qui permet donc de paramétrer le nombre de fixtures à charger.

Yop, je suis encore en formation sous HashKell, donc ça va un me prendre un peu plus de temps

Les exemples ne montrent pas comment charger des médias avec ces factories.

Donc, s'il faut plus de temps pour faire ça avec des factories qu'avec un outil tiers, l'outil tiers est plus intéressant.

Yop, je suis encore en formation sous HashKell, donc ça va un me prendre un peu plus de temps

Pas de soucis, de toute façon il n'y a rien de vraiment trash et je m'en sort alors que je suis loin d'etre un pro. Dans tous les cas quelqu'un de plus qui comprend ce qui a été fait, voir ne sert que de reviewer, ne sera pas de refus.

hmmm … et pourtant c'est faisable, et c'est bien ce qu'on fait déjà pour charger des medias pour tester notre module de gallerie. Après si vraiment quelqu'un veut aller chercher une solution ailleurs, pourquoi pas, mais n'oublions pas que les fixtures souffrent d'autres problèmes que les médias.

• le user staff des fixtures est un faux staff (contrairement au user staff qu'on charge dans les tests)
• les fixtures ne chargent pas de tutos out-of-the-box. Pas très pratique pour faire de la QA
• les fixtures chargent 2-3 topics, ce qui n'est pas non plus pratique pour la QA
• on a pas de commentaires de tuto/articles out-of-the-box
• plein d'autres manquent

Tout ces problèmes serait corrigés d'une traite et on en parle plus.