ZEP-08 Utilisation de git pour gérer les tutos et articles

Bonsoir à tous,

J'arrive après le débat, j'ai été redirigé vers cette ZEP que très récemment et j'approuve cette ZEP dans les fonctionnalités qu'elle pourra apporter. Par contre, j'aimerais faire quelques remarques :

1. Cette ZEP est bien trop énorme pour être développé par une personne. Plusieurs personnes doivent se mettre dessus et la ZEP doit être découpée en plusieurs ZEP. Nous ne sommes que des bénévoles qui développons ZdS sur notre temps libre. Impossible d'estimer correctement cette ZEP en terme de temps mais, à mon avis, dans le cadre d'une entreprise, elle pourrait prendre facilement 1 mois full time dessus (et je pense être gentil).
2. Actuellement, et le premier message de ce sujet le mentionne bien, nous utilisons Git comme un outil et non pas au coeur de la gestion des tutoriels et des articles. Un prérequis est donc de refactoriser le module des tutoriels et des articles pour centraliser l'utilisation de Git.
3. GitHub est l'une des plateformes de référence dans l'utilisation de Git mais cela ne veut pas dire que nous devons copier. Dans notre cas, nous ne voulons pas qu'un auteur "push" n'importe quoi. Il faut donc pensé à abstraire un certain nombre de choses pour pouvoir effectuer des vérifications lorsque l'auteur veut effectuer des vérifications. N'oubliez pas qu'un auteur n'est pas forcément développeur (aura plutôt tendance à ne pas l'être du tout). Il faut donc quelque chose d'extrêmement user friendly, pas des commandes Git brutes (selon moi).
4. Les "PRs" est une fonctionnalité non native à Git. C'est un mécanisme qu'il va falloir développer. Après, est-ce que nous voulons cette fonctionnalité ? Est-ce une bonne idée de lui donner le même nom ? Pour moi, non. Fonctionnellement, nous voulons qu'un utilisateur X puisse contribuer à un tutoriel Y. Techniquement, le fonctionnement sera semblable à une PR mais ça sera quelque chose de spécifique ZdS.
5. Globalement, ne pensons pas forcément GitHub. Discutons de ce que nous voulons fonctionnellement et nous réfléchirons après techniquement avec Git. Développer des choses autour de Git, nous n'y manquerons pas (raison pour laquelle il sera nécessaire de centraliser l'utilisation de Git).

Voilà, je viens un peu dépoussiérer ce sujet parce que cette ZEP a un potentiel énorme, malheureusement un peu trop énorme. Raison pour laquelle je pense qu'elle est restée au point mort (je n'ai pas lu tout le sujet, juste le premier message qui est censé résumé tout ce qui a été dit).

PS : Le premier message de ce sujet est difficile à lire. PSS : Joyeux Noël au passage !

Je suis globalement d'accord avec le message, mais je veux juste préciser un point. Une PR est "implicitement" une fonctionnalité native de git (envoyer un patch, discuter autour de ce patch, merger ou refuser un patch). Sauf que là tu as probablement la version Github, ce qui en effet est discutable (quoique… si le contributeur veut rajouter quelque chose, il peut être bon d'avoir une discussion "publique" - ou au moins auteur + contrib + valido - autour).

My 2 cents.

Cette ZEP est bien trop énorme pour être développé par une personne.

On est d'accord, c'est pas vraiment ce qui était prévu non plus. Actuellement, c'est juste la spécification qui est complexe car personnellement je ne maîtrise plus assez la techno pour continuer à mettre à jour la rédaction de la ZEP.

En cela c'est vrai que ta proposition de faire plusieurs ZEP serait pas mal.

Un prérequis est donc de refactoriser le module des tutoriels et des articles pour centraliser l'utilisation de Git.

ALors il faut que la ZEP 12 soit développé.

En fait, il faudra que :

1. ZEP 12 implémentée pour factoriser/améliorer globalement le code du module de tuto/article et préparer la venue des tribunes
2. choix important : évolution de GitPython vers py3 ou bien on prend libgit2 (py3 par défaut)
3. Autoriser le "git clone" en mode publique <= SECURITE

Globalement, ne pensons pas forcément GitHub.

En fait j'ai parlé de "PR" pour que chacun ait un point de comparaison. Le but est surtout de permettre de proposer une correction.

Je up parce que je n'ai pas reçu de réponses à mes questions. Les voici :

Je pense que pour les branches, etc… osef, autant juste mettre le bon hash du commit qui va bien. Libre a l'auteur / valido de choisir quel commit mettre en ligne (proposer), libre au valido de choisir quel commit utiliser (mise en prod).

Pour le fetch… Ouais osef de la limite a la rigueur. C'aurait été intéressant que le valido ait un accès ssh ceci dit (dans le cadre d'une manipulation plus complexe si besoin est)

Je pense que pour les branches, etc… osef, autant juste mettre le bon hash du commit qui va bien. Libre a l'auteur / valido de choisir quel commit mettre en ligne (proposer), libre au valido de choisir quel commit utiliser (mise en prod).

En fait ça pose problème ça… Par exemple je suis en train d’écrire une nouvelle partie, donc j'ai des commits en avance par rapport a la version en ligne, mais je veux faire une petite correction sur la version en ligne. Comment je fais ?

Dans la section "Gestion des branches", à quoi correspond les différentes branches mentionnées (sachant qu'aucune branche n'est utilisée actuellement) et les solutions proposée pour chaque branche ?

A l'époque où j'avais rédigé cette ZEP, le principe avait été celui-ci :

on a une branche "draft" puis 2 branche "prod" et "béta". A noter que plus tard dans le débat le concept de tag m'a été cité. Si la ZEP n'est pas à jour c'est simplement qu'à l'époque je ne comprenais pas vraiment ce concept, c'est un peu plus le cas aujourd'hui grâce au workflow de dev de ZDS, mais en gros, je pense que c'est clairement ce qu'il faudrait utiliser : un tag.

La notion de "branche" ne pourrait être utilisée que pour la correction communautaire : quelqu'un voit une faute, une branche est créée sur le dépôt avec la correction proposée et une sorte de "pull request" est générée.

Dans la section "Lier des dépôts distants", pourquoi il y a des problèmes de sécurité si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir (donc uniquement la lecture de ces dépôts) ? Pourquoi discuter du système d'authentification par SSH ?

parce que rien n'a été décidé quant au "si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir".

Dans la section "Gestion des branches", à quoi correspond les différentes branches mentionnées (sachant qu'aucune branche n'est utilisée actuellement) et les solutions proposée pour chaque branche ?

A différencier le boulot de l'équipe de validation de celui du (des?) auteur(s). À la base c'est ça, mais ce débat a été "empoisonné" par celui ayant lieu au même moment à l'époque sur le workflow de ZdS itself. Du coup, je pense qu'il faudrait relire les argument à tête reposée et séparer ceux qui n'avait pas forcément à voir de ceux qui on vraiment de l'intérêt (git flow ou pas, toussa).

Dans la section "Lier des dépôts distants", pourquoi il y a des problèmes de sécurité si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir (donc uniquement la lecture de ces dépôts) ? Pourquoi discuter du système d'authentification par SSH ?

Pour moi, SSH, pour des problèmes liés à ce qu'est un système UNIX. Je m'explique: pour donner un accès ssh à qui que ce soit, il faut que ladite personne aie un compte sur la machine hôte. Donc déjà, y faudrait que ça soit le cas et donner un lien compte ZdS <-> compte sur la machine. Ensuite, y'a la gestion des droits pour éviter que tout un chacun fasse n'importe quoi n'importe ou. Et quand je parle de "droits", je parle ici de la version "UNIX" de ceux-ci (écriture/lecture/exécution) : qui a le droit d'écrire quoi ou ? Alors pourquoi pas pour les validos, mais ouvrir ça à n'importe qui, ça me semble la porte ouverte à n'importe quoi (sans compter les failles de sécurité si un petit malin se met à uploader des scripts pythons exécutables).

Quand à git, ça revient à peu près au même : il faut que quelqu'un spécialisé dans la quesion ouvre le bon port pour que ça soit permis, donne les bonnes permissions au bon endroit et ainsi de suite. C'est donc faisable, mais … Est ce qu'on a les ressources/moyen ? Et pareil, il faut penser à la sécurité, ainsi qu'à l'aspect place que ça prend et qui peut pusher quoi (est ce qu'on accepte les images ? Comment?).

gitolite et gerrit font du contrôle de droits via les clefs publiques utilisées par ssh sans avoir besoin d'un compte par client, toutes lez connexions ssh appartiennent à gitolite/gerrit.

Pourquoi faut-il contrôler les droits d'accès ? A la base, l'exigence est pensée pour le push, mais c'est nécessaire même pour un clone. L'auteur d'une œuvre est le seul à pouvoir décider de sa publication, on ne peut pas permettre à n'importe qui de cloner un dépôt car ceux ci peuvent contenir du contenu inédit.

Et sinon, Pierre à raison, c'est très complexe, c'est pour ça qu'on n'envisage pas de le faire bous même et que les mots gerrit/gitolite reviennent si souvent dans la discussion.

Je serais bien incapable de faire avancer les choses sur cette zep, mais elle me semble plutôt utile. Quoi de neuf de ce coté depuis presque 1 an ?

Pour tout te dire : rien. C'est extrêmement complexe et la ZEP-12 a pris les deux tiers de l'année en question.

A mon avis, cette ZEP est l'un des chantiers les plus importants à mener pour ZdS mais elle demande énormément de travail (vraiment beaucoup beaucoup). Il faudrait des ressources, des connaissances et de la motivation.

C'est dommage parce que si ZdS intègre toutes les promesses de cette ZEP, je considèrerais ZdS comme une alternative GitHub sérieuse pour tout ce qui concerne du contenu. Ca serait assez énorme.

en effet. Mais il faudrait des devs front.

Pourquoi des devs front ? Si on peut manipuler dans un premier temps directement les dépôts, ce serait bien. On pourrait alors travailler plus facilement via GitHub/GitLab/autre.

Si on peut manipuler dans un premier temps directement les dépôts, ce serait bien.

en soit, manipuler un dépôt on sait djéà le faire car… chaque contenu est un dépôt.

Le vrai problème c'est qu'il faut savoir :

• quoi faire
• quand le faire
• comment le montrer à l'utilisateur

Si github a explosé gitlab ou btbucket c'est avant tout car ces gens là ont fait un front qui marche du feu de dieu. Il suffit de voir le module de diff avant et après le passage d'une personne qui sait comment montrer un diff à l'utilisateur.

Donc en fait il faudrait carrément une spec du front AVANT celle du back.

en soit le back on peut très bien le rendre sous la forme d'une API appelable en JS donc ça veut dire que le front peut être développé avec des "mock" et ensuite on branchera le truc qui va bien.

en soit le back on peut très bien le rendre sous la forme d'une API appelable en JS

ça serait même préférable.

ça laisse la possibilité à n'importe qui de développer une UI sympa si celle du site ne lui convient pas, …

C'est pas tant des dev fronts qui manquent à mon sens, mais plus une spec "concrète"/UX. L'implémenter en front, ça va être long chiant, va falloir choisir la/les bonne(s) méthode(s) et techno(s). Mais d'abord faut se représenter visuellement le truc, savoir à quoi ça pourrait ressembler concrètement.

Et là, c'est presque pas encore le boulot d'un dev front. Mais c'est vraiment (très) dur.

Bonjour à tous.

Comme je l'ai dit sur twitter, je vais développer cette ZEP. Par contre, son développement ne démarrera que lorsque quelqu'un aura décidé qu'il m'aidera à développer. Je ne commencerai pas cette ZEP si je suis seul.

Du reste, voici le plan d'action auquel j'ai pensé :

Ce plan d'action est immédiatement raisonné à partir des choses de la zep-12 qui ont fonctionné ou échoué.

Première étape : Amélioration du modèle et de l'interface de collaboration

Avant de passer à des intéractions complètes avec git, il faudra d'abord être clair sur ce qu'on veut versionner. De plus, il faudra être très "user friendly" dans la manière de versionner et de présenter les conflits d'édition aux gens.

Cette première Etape, appelée ZEP 8.1 donnera lieu à une PR en soit. En effet, développer la ZEP complète puis merger, a montré durant la zep-12 que c'était casse gueule et source de nombreux bugs (templates incohérents, bugfix mal mergés, demandes mal maîtrisées et surtout le code produit met 1 an à arriver en prod alors que des bugfix et features intéressantes sont codées depuis longtemps).

Cette PR ZEP 8.1 packagera :

• une nouvelle version du manifest.json qui versionne ce que la zep-12 n'a pas versionné alors que c'est souhaitable qu'on le versionne comme le logo.
• le bugfix de #3251, #3134 (il faut améliorer les différents chargements), 2532 (tant qu'à faire, dans la zep qui parle de git)
• Faire valider le manifest.json par un schéma json
• En ce qui concerne #3251, bien que le débat soit encore possible, il est selon moi nécessaire d'avoir une interface en trois blocs :

PS: notons que le theirs/mine est déjà codé dans un templatetag

Deuxième étape : correction par simple PR

Une faute d'orthographe? une image qui est en http? une faute factuelle passée à travers la validation? Proposez votre correction par PR !

Une nouvelle fois c'est en plusieurs bouts que nous feront ça :

• première étape : faire une PR sur un extrait, une intro ou une conclusion. Pour faciliter les choses, il faudra être connecté pour cela. Un bouton apparaîtra lors d'une action spéciale (survol, click sur une roue dentée? les dev front/UX vous pouvez apporter votre expertise) et qui permettra la proposition. Une fois la proposition faite, un MP est envoyé aux auteurs, et lrosqu'ils visiteront leur version brouillon, dans la barre des actions des extraits, en plus éditer, déplacer, supprimer, ils auront droit à une page "voir l(a|es) PR" qu'ils pourront accepter ou refuser une par une. Première étape : on n'a donc que "accepter" et "refuser". La PR doit donc pouvoir être mergée automatiquement. Si elle ne peut pas l'être, le membre qui l'a faite se verra proposer une alerte du style :

Il semblerait que l'auteur ait déjà corrigé des erreurs dans cette section. De ce fait, votre correction ne peut être proposée automatiquement. Afin de faire profiter l'auteur de votre travail, désirez-vous lui envoyer vos propositions par message privé? OUI/NON

En deuxième étape, une résolution manuelle pourra être proposée mais surtout le front évoluera et on pourra au click droit sur un paragraphe avoir l'option "proposer une correction". et lorsque le champ de proposition de correction apparaîtra, il se positionnera directement sur le bon endroit !

Une nouvelle fois, une fois qu'on a ça, on fait une PR sur le dépôt principal de zds.

troisième étape : lien avec le monde

Proposer en sus de la navigation sur le site, de :

• lier un contenu à un github/gitlab/bitbucket (ajouter un remote), par soucis de cohérence technique, pour l'instant, on se contente de jouer avec les dépôt git, désolé les gens qui aiment mercurial ou HG. On prend aussi ces trois services là pour l'exigence suivante :
• Utiliser l'API de ces services pour que zds puisse faire des PR sur ces remotes (zds se place alors comme un dépôt décentralisé) lorsque l'utilisateur le demande (bouton à coder en AJAX)
• Importer un tutoriel depuis un dépôt git existant : basiquement, on fait un clone, on check que le manifest.json existe, on fait les modifs adéquates pour que ça soit zds-compatible, on fait une PR au dépôt. Si le manifest n'est pas présent, on suppime le dépôt et on prévient l'utilisateur. Il serait d'ailleurs intéressant de proposer cette expérience via une interface ajax qui affiche des barre de progression etc.

C'est gentil de te proposer !

Du coup, pour les dépôts comment va tu faire ? tu partirait sur l'idée suivante qui est sur la première page:

un des dépôts représente le tuto en cours de rédaction, il appartient à l'auteur qui peut en faire ce qu'il veut (le clôner, y pousser des changements, etc.) ; l'autre représente le tuto publié sur le site, il appartient aux validos qui peuvent accepter les pull requests des auteurs. Ça simplifie pas mal la gestion des droits, étant donné que les ownerships sont déterminées dépôt par dépôt (et non branche par branche ou tag par tag).

et pour les branches ? tu as choisis quelles options ?

un des dépôts représente le tuto en cours de rédaction, il appartient à l'auteur qui peut en faire ce qu'il veut (le clôner, y pousser des changements, etc.)

y'a ça aussi et pour l'instant c'est impossible : nos dépôts ne sont pas des dépôts bare. Donc il faudrait ajouter une nouvelle étape à la zep

et pour les branches ? tu as choisis quelles options ?0

1 pr de correction = une branche finalement.

Mais la spec initiale est outdated complètement. A l'époque je comprendais aps trop git

Excellente initiative, on voit bien que sur le plan technique ça peut apporter énormément à ZdS. On voit aussi que les possibilités sur le plan fonctionnel offertes par cette MeP sont nombreuses (PR de correction principalement). Donc c'est vraiment une excellente nouvelle.

Un truc que je me demandais et dont j'avais oubli de faire mention plus tôt (désolé :\ ) c'est : cette ZEP est intimement liée à l'API des tutos non ? Toutes les actions dont tu parles (rajouter une origine, soumettre une PR de correction, …) devraient être disponibles par API REST (ça ouvrirait la voie à des espèces de webhook, mais pourquoi pas à des éditeurs externes, etc.) ?

J'imagine que vu qu'on est à t0 c'est pas gênant (il faut coder l'API : au sens programmatique, pas REST) du machin avant d'imaginer en exposer les primitives, mais autant y penser assez tôt, non ?

Bon courage !