Bon Dredi à tous
Bon mais mon mail était trop lourd il a été bloqué a l'envoie sur la liste,
Donc je le renvoie sans mise en forme en texte brut, déjà c'est pas en morse, c'est plus facile a lire.
j'ai essayé de répondre assez clair, sans trop dériver, sans vexer personne , ça m'a pris plus de temps et je sais même pas si j'ai réussit 
Le 21/05/2019 à 10:00, Eric Lupinacci a écrit :
Hello,
Le mar. 21 mai 2019 à 07:29, GraphX <arnaud.berard@mister-graphx.com <mailto:arnaud.berard@mister-graphx.com>> a écrit :
Ca confirme rien du tout et j'ai l'impression que tu dit sans
savoir ou avoir même essayé (comme git ou pakagist/composer, …)
un peut ronchon quand c'est pas du made in spip quoi ^^ Comme
si des millions de devs ne pouvaient pas arriver à la cheville du
niveau de reflexion d'une dizaine de spipeur-se francophones,
autour d'un framapad et quelques echanges mails… .
Oui hier j'ai dit quelques conneries, je le reconnais sur la typo et la syntaxe MD.
Ca ne vaut pas je pense le procès d'intention que tu me fais sur Git, packagist, composer
Je ne fais pas de procés, je compare les deux, faisant un amalgame avec des légendes "urbaines" de choses dites sur IRC, dans des échanges, ce n'est pas toi qui est ciblé directement, mais plutôt un discours collectif, une rumeur persistante que certains propulse, véhicule, et basé sur des apriori surtout motivé par une peur du changement j'ai l'impression, (je n'ose pas me dire que c'est uniquement un intérêt personnel).
Et le tout de ces légendes urbaines, bloque l'évolution de la forge spip déjà appelons la comme on veux, ce n'est pas une barrière technique, mais plutôt un blocus technique, ça j'en suis certain car avec mon petit niveau j'ai répliqué un serveur de paquet privé n'utilisant que git et piochant dans github et gitlab... donc si moi j'y arrive c'est que c'est faisable.
Moi j'aime les nouveaux outils, les nouvelles libs, c'est noel quand je trouve un nouveau truc pour jouer avec ^^
je dis qu'on ne pourra plus/pas faire sans, et il faut essayer de comprendre le workflow qui est eprouvé par des dizaines d'autres cms, adopté par des millions de devs... (genre la pensée chinoise du Dredi "quand tout le monde est fou autour de toi, méfie toi, le fou c'est peut être toi" )
Et comme tu est plus "influenceur" que moi, core dev, j'essaye de te faire changer d'avis en me disant que si toi tu passe a des outils plus modernes, d'autres suivrons (…simple ^^ ne crois pas que je m'acharne sur toi lol j'estime ton travail à juste titre et je suis tes écris depuis que j'utilise spip ),
Donc oui je vais tenter de te faire changer d'avis (toi ou d'autres peut être) et au moins partager le mien
- on peut écrire des documentations complexes sur Git{hub|lab} et en faire des documentation finalisée, fonctionnelles et collaborativement.
- oui composer a des gros atouts comparé a l'outil actuel svp smart paquet
- oui git a de réels avantages comparé a svn
- au final oui le workflow proposé par les plateforme de type github/lab doit remplacer l'actuel vision de forge
- composer quand a lui est un gestionnaire package plus sur et fiable que l'actuel manière de gérer les paquets
je détaille et argumente ensuite mon avis et comment j'ai subit la transition, ce que j'en ai retenu.
ni le dédain sur les spipeurs francophones qui ne le méritent pas.
Je n'ai pas de dedain pour les francophones on m'as déjà taxé (entre autre) sur cette liste de :
developeur franchouillard ethno-centriste (j'ai appris un mot ce jour la )
mdr on est moins de francophones au niveau mondial donc forcément on se prive de l'ouverture avec les autres en ayant un outil privilégiant un public francophone (doc source, langage de boucles, fonction, api sont en français). Donc si on fait pareil avec les libs, les technos, les outils, … ne pas tourner en vase clos tel était mon propos.
Désolé si j'ai vexé des gens du coup, c'est une vérité vrai et je suis mm étonné d'avoir a me justifier sur ça
J'espère ne pas être celui qui bloque le développement de SPIP depuis 8 ou 10 ans, ça serait bien prétentieux...
Peut-être devrais-tu t'appliquer ce que tu me reproches: relis ce que j'écris, j'ai écrit et toutes les propositions que j'ai faites depuis des années, peut-être alors tu auras une vision plus exacte...
Je t'ai lu et je te lis avec attention , j'ai pas dit que tu bloquais le developpement, tu fait plutot avancer les chose, j'ai dit on en parle depuis 8 ans et sous entendu on entend encore les mm prégugés… je parlais plus de la forge spip zone que de spip en plus.
Après tu as tout a fait raison, je devrais commencer par me l'appliquer à moi même, moi aussi je suis passé a tout git y'a que 1 an réellement alors que déjà les developpeurs de ma boite il y'a presque 9 ans me disait de passer a mercurial ou git,que svn c'était has-been.
Mais entre temps j'ai changé tout mon workflow d'intégration, ré-écris mon framework css, tout passé a scss, créé un outil pour le documenter, passé a node + gulp pour compiler le tout, utiliser yarn + eyeglass pour gérer les dépendances de mes composants scss, ça m'as pris du temps … et j'ai finis par git alors que j'aurais peut être du commencer par ça.
https://gitlab.com/mister-graphx/fragments/Builder
https://gitlab.com/mister-graphx/fragments/framework
https://gitlab.com/mister-graphx/frontdoc + https://gitlab.com/mister-graphx/little
La depuis quelques semaines je travail avec composer, sur un projet php utilisant principalement des composants symfony et donc j'ai eut l'occasion de me remettre a composer, en allant plus loin, et effectivement oui si je pouvais organiser mes distribs spip aussi surement , rapidement , ce serait mieux.
Après si on en revient à MD, l'expérience récente m'a un peu déçu avec les tableaux, les guillemets et certaines listes (je me rappelle plus exactement le cas).
Mais je te rassure c'est la même chose avec SPIP.
Je pense que je suis 20 à 30% plus efficace pour rédiger une documentation correctement typographiée et présentée avec Word ou Google Docs qu'avec SPIP ou MD.
Le problème des traitement de texte, que j'ai vu et aussi avec la syntaxe spip, c'est que les gens utilise un h1 parce-qu’il est plus gros, ou un h2 parce-que dans la charte il est centré : et ça c'est la cata !! (y'a des dizaines d'articles a ce sujet)
Alors oui quelqu'un-e qui utilise les titres correctement et qui sait ce qu'il-elle fait, le problème du traitement de texte c'est que ça parait simple et les gens font du joli :
- ET c'est pas leur job : leur job c'est de fournir un contenu (déjà c'est parfois dur) rédigé et structuré
d'ou le fait que le plugin intertitre affiche les balises utilisées H1,H2
Un doc correctement structuré il devrait n'utiliser que
- titres h1 a h6
- bold,italic,cite
- paragraphe
- listes
et c'est tout , donc en markdown y'a pas de syntaxe compliqué a retenir c'est ce qui est autorisé généralement dans les blocs texte des page builder, et ça suffit pour faire un plan sémantiquement correcte (c'est surement pour ça que c'est ce qui est livré en raccourcis standard avec spip hors titres).
mm j'aime bien que les documents ne soit pas inclus dans le texte mais juste en référence, on incorpore après, en plus ça m'évite d'exporter l'image pour la traiter ensuite.
Pour googleDoc j'utilise j'en conviens, uniquement car on peut discuter autour du doc et que les gens sont habitués a word, mais si tu exporte en html pour le publier a un moment :
- le markdown restera plus propre car c'est fait pour générer du html valide.
- Word OpenOffice génère du html pas terrible et difficilement utilisable ensuite hors papier.
Autre avantage, un article rédigé au format markdown sera donc publiable dans quasi tout les cms ou dans un générateur de site statiques, ou un espace gitLab-pages gitHub-pages, ou sur dropbox paper aussi je crois.
bon je viens de l'imprimerie/compo donc nous c'était ça un doc, maintenant les gens mélange la mise en forme et le traitement des contenus résultat faut récupérer des images plus ou moins abimées par le soft, ou se trimbaler un doc qui pèse un poids monstrueux car les images sont trop lourdes et embarquées dedans.
Et il faut un logiciel du coup pour pouvoir utiliser les révisions d'un document, et envoyer par mail genre doc_v1, doc_v1b, doc, ou sinon dropbox qui as un suivi de version mais pas de diff je crois juste un etat a une date.
J'utilise un traitement de texte pour faire un courrier en somme => c'est fait pour ça, y'a des logiciels pour la mise en page.
Et encore j'utilise les traitements de texte depuis bien 30 ans et en 1995 j'ai utilisé un logiciel sur SUN à Alcatel qui s'appelait Alice avec lequel tu ne pouvais pas faire un doc pourri; jamais je n'ai retrouvé un logiciel de cette efficacité.
Bref, je pense que je suis d'une génération qui préfère une doc papier bien présentée avec un sommaire qui explique la logique de ce qu'on va lire plutôt qu'une longue page MD ou SPIP. On ne se refait pas.
Oui sur le web c'est déconseillé de faire de long articles, et en rédaction commencer par l'index / plan
y'a t'il besoin d'un wysiwig pour comprendre la hiérarchie la : Honnêtement je comprends mieux la hiérarchie en regardant le code que le rendu…
# Maintenir un mutualisation avec Git
## Quelle stratégie , mono-repo ou multi ?
## Sur le serveur
### Initialisation/création du dépot
### Mise a jour des plugins
## En local
- l'importance des niveaux de titres correctement imbriqués pour générer un index automatique et une navigation dans l'article, le truc qui m'as fait adopter markdown très vite,
- De ne pas faire des articles interminables : comme c'est le cas actuellement sur contrib par exemple, ou on a un article pour toute la doc dans 95% des cas (je critique rien c'est un constat) Ce qui au final reviens pour moi a un readme stocké dans une base de donnée, pour pouvoir être éditable.
- Beaucoup d'outils markdown te propose un index automatique basé sur les niveaux de titre.
Et dans le genre, WYSIWYG c'est surement le mal absolu mais c'est beaucoup plus inclusif que la syntaxe SPIP ou MD. Et si MD permet de faire que le WYSIWYG passe du coté clair de la force c'est une très bonne raison pour y passer (sur CodIMD l'éditeur avec la syntaxe à gauche et le rendu à droite est très efficace et rassurant, mais il faut une page assez large pour ça... :p).
ça c'est le point fort, les outils autour de la syntaxe markdown , comme c'est très utilisé, y'a pleins de trucs: après de la a avoir un vrai wysiwig, ça existe mais je sais pas si ça me serait utile, je me concentre plus en mode texte que en mode mise en forme. Sur mac j'avais acheté LightPaper qui est pas mal (y'a un sommaire auto), mais je l'utilise quasiment plus tu pouvais spéciifer la css de ton site pour avoir la preview quasi réelle.
A tester par exemple atom sans aucun addons supplémentaires ça fait un super éditeur markdown avec la preview à droite ou en bas, ou tu veux (clic droit copier au format html, enregistre au fromat html ^^), la coloration (titres, gras), des snippets,
Et la (je te cherche ^^) tu combine la rédaction de doc + git qui est intégré aussi en natif
ça gère les état git de tes fichiers avec les lignes, la diff, … tu peut citer une discussion ou un projet dans ton commit ça te fait les liens, et la personne concerné reçoit un mail pour aller lire , voire et donner son avis (sur GitLab en tous cas). d'ou le fait que je suis pas fan des framapad,vox et autres, la autour d'un fichier texte y'a des issues, des discussions, un suivi dans une seule interface.
Donc sans addons sans quitter ton éditeur (en admettant que tu ai déja cloné la doc v1 en local ^^ sinon y'a un git clone a faire)
Scénario :
- Tu peut créer une branche locale de ta doc : prepare v2 (depuis ton éditeur - 1clic il te crée la branche)
- revenir instantanément sur la doc de la v1 pour corriger un truc rapide (depuis ton éditeur - 1clic, il bascule l'état des fichiers instantanément car avec git tu as a dispo en local)
- quand t'as suffisament avancer ta doc prepare v2 et que c'est montrable la tu décide de pousser la branche sur le dépot et de commencer a discutter autour (1 clic ) et dans ton commit tu cite les gens, les issues (mail et taches sont automatiquements assignées)
- A ce moment on t'apelle et on te dis ha la doc v1 y'a une boulette, hop tu repasse en v1 toujours depuis ton éditeur et tu corrige, tu envoie direct.
- la tu raccroche et tu repasse en branche doc v2 (toujour 1 clic depuis ton éditeur) en priant pour que durant 5min tu puisse continuer ton boulot sur la v2 sans qu'on te prenne le choux avec la v1 ^^.
Compliqué ?
la avec svn si on veut faire la même **pour moi** c'est pas aussi simple, et surtout pas aussi rapide car svn ne stoque rien en local donc tu rapatrie tout a chaque fois, lourd, et long.
et avec un traitement de texte : c'est pas collaboratif, aucun suivi ou difficile, pas de diff, pas de discussion autour, pas de notifications auto, etc …
Pour les autres calomnies ;-), Git et Composer.
Je n'ai rien contre, bien au contraire parce qu'il semble que ce soit un passage obligé pour que certains s'intéressent ou se ré-intéressent à SPIP.
se ré-intéresser au travail collaboratif sur l'espace de la zone serait plus juste … spip et les plugins existe en dehors , je ne dépose que très peut de projets sur spip-zone, je ne suis pas le seul … ça dépend si on utilise svp, si on a un serveur de paquet privé, comment on installe ses site et si on les met a jour via git, …
Mais il ne faut pas que cela exclut d'autres contributeurs avec des profils moins "dev".
Tout a fait chacun a son niveau, toute remarque ou contribution, correction typo ou autre est bonne, c'est pas pour autant que cette contribution ne doit pas être validable, suivie, discuttée avant d'être publiée et incorporé au paquet, c'est la l'avantage des interface gitea, github, gitlab et du workflow qu'ils propose.
Le truc c'est que quand on parle de pull-request, fork j'ai l'impression que c'est un gros-mot ? (humour encore hein ^^)
Moi ça me parait plutôt sain comme démarche :
> bonjour je suis pas dev, mais j'ai vu que dans la chaine de langue y'avait ça > pull request
>> oui c'est cool mais t'as oublié une virgule dans ton array ça pete tout : essaye encore
> j'ai corrigé la virgule > pull request
>> cool , merci : < merged
Non ? y'a tout la : relaxité, méthode , souplesse
Pour moi, qui suit un spipeur occasionnellement assidu mon but est de créer de la fonctionnalité et de ne pas perdre de temps sur les outils.
Ce type de changement doit être accompagné c'est tout.
Donc depuis quelques jours j'ai réactivé mon github, j'utilise Git/Github suivant l'ordi.
Je reste sur ma position initiale : Git fait tout et même le reste et c'est quand même une usine à gaz alors qu'on en utilise qu'une infime partie la plupart du temps.
Mais si on détoure bien son environnement on arrive à reproduire le checkout/commit/update de SVN qui suffit dans 95% des cas et des utilisateurs.
Je suis très fan par contre de Github et de son desktop qui arrive bien à faire émerger l'essentiel de git assez simplement.
J'ai utilisé au début de mon passage, maintenant c'est intégré a tous les éditeurs de texte comme expliqué précédement avec branches locales etc, les commande que je doit taper dans le terminal c'est git remote … git push origin quand j'initialise le dépot le reste se fait depuis l'éditeur de texte quasiment, ou sur le site du dépot (merge).
Avant j'utilisais smart-svn, depuis que je suis passé a Git c'est depuis mon éditeur ou terminal
A noter aussi que un terminal comme iTerm a quand mm l'auto-completion de commande, donc tu ne les tapera qu'une fois ensuite quand tu tape git il te suggère toute les commandes que tu as déjà utilisé… (même les mauvaise ^^)
Pour SPIP et son écosystème de plugins, le git SPIP, Gitea, etc, je suis plus dubitatif, je trouve Github plus facile d'accès mais c'est peut-être un point de vue subjectif.
J'utilise gitHub, mais j'ai finalement choisit gitLab pour mes projets :
- les projets > sous projets son plus pratiques, plus souple que sur GitHub,
- l'interface est traduite en français pour les clients qui prefère tiket que issue
- pas aussi user friendly que github mais je trouve plus puissant sur certains point, notamment le WebIDE (utile pour le non dev qui veux éditer un readme), les liens auto, les snippets par projet ou globaux , la syntaxe et les possibilités markdown ^^ etc … franchement je recommande …
Je peux dire qu'aujourd'hui je suis aussi presque aussi efficace en Git qu'en SVN (j'ai pas refait mon petit script svn de mise à jour de mes sites de dev) mais cela ne m'apporte rien de plus pour l'instant.
je suis plus productif avec Git et surtout plus sécure, ça m'a obligé a passer a une organisation plus cohérente et plus sure finalement.
Ce que ça m'apporte :
- créer des branches locales indépendantes du dépot si besoin, et pouvoir switcher de l'une a l'autres rapidement pendant mon travail, sans quitter mon projet.
- pouvoir fusionner mes branches locales si besoin, revenir sur une modif, tester avant de pousser sur le depot
Idem sur le serveur, on peut switcher d'une branche a l'autre beaucoup plus vite sans tout re checkout
Le fait que ce soit natif dans mon éditeur m'as fait gagné du temps aussi, du confort, gagné de la ressource et mémoire en utilisant une appli en moins, mais ça c'est pas relatif directement a git…
Composer c'est plus compliqué pour moi.
Déjà je pige pas trop le système dans son ensemble, et j'ai surtout du mal à entrevoir le lien entre le dev et la production.
C'est simple ça remplacerais une partie au moins de svp pour l'install, et smartpaquet pour les service pakagist . C'est idem que Yarn ou npm mais pour le php (ça tout le monde à compris ^^)
Chaque plugin est un pakage, qui peut requerir d'autres paquets, et ton appli est un paquet qui va requerir des paquets ^^
Jusque la, tu me dis et alors svp ça fait pareil mais c'est des paquets et pas des packages !!
C'est pas faux, Mais non … Chacun des requis pouvant etre défini par un
- namespace : une version
une version = un tag git sur le dépot pakagist, ou sur un depot local, ou si tu définie des repos vcs c'est traduit en une url vers un repo.
LA différence c'est que composer s'appuie sur un etat git/svn plutot que sur un numéro de version dans le paquet (considéré comme très aléatoire … cf la doc de composer)
Donc tu gère ultra finement toute les dépendances et leur imbrications, avec l'assurance d'un état instantané sur le dépot.
Ce n'est pas le cas du gestionnaire de paquet de spip ni de svp
Après il a d'autre avantages, comme le .gitattributes qui te permettra de ne pas installer la doc ou les test en prod , etc
Ma seule alerte concerne le référentiel des plugins qui tourne autour des XML et de smart-paquets.
Smart paquet n'as plus vraiment d'utilité si tu passe par composer, on passe pas par des zip on installe des sources depuis un dépot git/svn, c'est le point fort, ainsi que aussi un cache qui te permet de pas tout re-checkout a chaque install.
Après c'est créer un pakagist like pour spip ou utiliser pakagist
SVP pourrait devenir une interface de composer, je sais pas comment c'est fait chez Drupal faut regarder, ils utilise symfony donc composer + yarn pour le front
Je dis juste attention, il faut préserver notre capacité à alimenter Plugins SPIP/Contrib surtout qu'on est en train de le refondre pour le rendre plus accessible et performant.
Super chantier, y'aura des issues/tikets ? ça va apporter juste la doc ou des outils pour faciliter les développement et le suivi de bug SAD ?
J'ai toujours soutenu l'idée que (mais la aussi je sais que je passe pour un extra-terrestre,ou un débile quand je dis ça)
- sur pakagist, npm, etc y'a le readme d'affiché ^^ en toute simplicité et toutes les infos possibles (tags, depot, mainteneur, dependances, dependances de dev, )
- c'est plus facile pour le mainteneur-euse d'avoir tout dans le même dépot la doc , le source… y'a github-page ou git-lab-pages , ça aussi c'est que du bonus
Exemple :
Le dépot https://github.com/mistergraphx/TW5_GX_edition
La doc : https://mistergraphx.github.io/TW5_GX_edition/
Pas de cout de maintenance, gratos, pas de cout serveur, pas de cout humain c'est clair, propre, rapide
J'ai une branche doc dans le dépot, une master, je change de branche en local, je fait --build, je commit , et la doc est a jour
2 clics 1 commit une ligne de commande
Et c'est de plus la structure recommandée d'un dépot chez composer, npm, etc
Voilà.
Quand je relis ce mail ça me déprime de devoir me justifier sur tout ça.
Je me demande si il n'est pas là, le vrai problème de SPIP.
Mais tu n'as pas a te justifier, je tiens le débat car toi on t'écoute ^^ tu rédige et depuis longtemps, tu contribue énormément, comme dit au début … un influenceur, moi je suis un nain-posteur ^^ (rapport aux mails et forums)
Je te convaincrais pas en un jour, je pense
++
Eric (qui fatigue et déprime un peu).
Bises et déprime pas
----
spip-zone@rezo.net -https://listes.rezo.net/mailman/listinfo/spip-zone
--
Bonne journée
Arnaud B. (Mist. GraphX)
