Un Zest'Meeting

La rencontre des dezesteurs

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

Bonjour à tous,

J'ouvre ce topic pour annoncer le premier meeting des développeurs back-end régulier sur ZdS. L'idée est de réunir au moins tout ceux qui ont déjà participé au développement back-end de ZdS pendant environ 1h, pour échanger de manière plus directe sur la suite.

Avec la rentrée, le début des activités, certaines choses risquent de changer/évoluer, l'implication des développeurs ne sera peut-être pas la même. A coté de ça, nous avons pas mal de ZEPs à suivre, et surement des nouveaux membres qui vont débarquer. Je pense donc que c'est le moment de faire un point sur la situation et de voir ensemble vers ou est-ce qu'on voudrait aller.

  • Date : Jeudi 28 aout 2014
  • Heure : 20h
  • Lieu : IRC (le canal sera donné plus tard)
  • Les sujets abordés :
    • La chaine de développement
      • La doc : ses manques, ses zones d'ombres, les dépendances du projet
      • Le workflow : ZestFlow, QA, Intégration Continue
      • Les modules sensibles : tutoriels, etc.
      • Le qualité du code : lisibilité (PEP8), refactoring, bonnes pratiques
      • Les goulots d’étranglements et optimisations : profiling, …
    • Les MEPS
    • Les ZEPs

Vous êtes tous les bienvenue, mais pour ne pas que ça dure trop longtemps la parole sera donnée priorité à ceux qui connaissent le code en général et le back-end en particulier. Et les logs seront archivés et collés dans ce topic.

NB : Pour éviter que ça dure trop longtemps, ce premier meeting ne concernera que le back-end. Mais je pense qu'il faudrait en faire aussi pour le front-end ou ça parlera plus de design, ergonomie, référencement, accessibilité et tests fonctionnels.

Merci d'avance à ceux qui seront là.


Résumé des meetings

Meeting 1 - 28 aout 2014

Meeting 2 - 30 septembre 2014

Meeting 3 - 4 novembre 2014

Meeting 4 - 9 décembre 2014

Meeting 5 - 12 janvier 2015

Meeting 6 - 10 mars 2015

Meeting 7 - 20 avril 2015

Meeting 8 - 3 juin 2015

Meeting 9 - 1 octobre 2015

Meeting 10 - 13 janvier 2016

Édité par elyppire

Staff

Parce que ça concerne que le back, qu'il faudrait changer les modes du chan et mettre toute l'équipe de dev en voice/op ? On sera plus au calme sur #zds-meeting je pense.

"I think that it’s extraordinarily important that we in computer science keep fun in computing." – Alan J. Perlis

+2 -0

Et alors ? Il faudra quand même mettre "l'équipe de dev" (qui, je le rapelle, peut être l'ensemble des contribs… vu le caractère du projet) en voice sur le canal meeting.

My two cents.

"Meh." Outil de diff PHP : Totem

+1 -0

Mais je pense qu'il faudrait en faire aussi pour le front-end ou ça parlera plus de design, ergonomie, référencement, accessibilité et tests fonctionnels.

front-end = sandhose et moi-même jusqu'ici… en gros on le fait déjà sur Skype. Pour l'instant on bosse sur de l'opti, de mon côté j'avance sur le WYSIWYM qui devrait arriver dans les semaines à venir d'où le break sur ZdS. Mais en somme, ça n'a pas d'intérêt à l'heure actuelle car on est trop peu et il y a peu/pas d'activité, promis je reviendrais d'ici peu (à la rentrée ou un tout petit peu plus tard).

Je viendrais peut-être quand même voir ce qui se passe au back pour être au jus.

Staff

de mon côté j'avance sur le WYSIWYM qui devrait arriver dans les semaines à venir d'où le break sur ZdS

Tu devais pas nous faire une doc avant ? Tu nous as dit toi même que tu en aurais pas pour longtemps.

+8 -0
Staff

front-end = sandhose et moi-même jusqu'ici… en gros on le fait déjà sur Skype.

Alex-D

En fait vous êtes déjà plus que 2 sur le front-end.

Le message que je lis me fait penser qu'on (on : pronom indéfini) aurait tout intérêt à organiser aussi ce genre de réunions sur quelque chose de plus public que Skype, pour y faire venir tous les intéressés.

Et aussi que la doc front commence à devenir urgente.

En fait vous êtes déjà plus que 2 sur le front-end.

SpaceFox

On va pas chipoter pour ça maintenant… :p

N'empêche que même si ce Zest'Meeting concerne que le back, je pense qu'Alex et moi sommes quand même concernés… J'veux dire, ce que nous renvoie (et surtout ce que nous renvoie pas) le back dans les templates nous concerne aussi… Pareil pour l'API ou autre :-° (en plus, dès qu'on change quelque chose côté front sans prévenir le back, on nous tape sur les doigts :D )

Par rapport au caractère "non public" de Skype, sache qu'on discute pas tellement de décisions à prendre, mais plus de problèmes plus techniques qui ne concernent que nous deux…

Édité par Sandhose

"I also don't trust Caribou anymore." — Joss Whedon

+0 -0
Staff

Je pense que l'idée du caractère "back-only" de ce premier meeting a deux objectif :

  • Faire un essai avec un nombre raisonnable
  • Rester centrer sur des discussion "back-only" (donc exit tout ce qui est renvoyé au front).

Dans tous les cas :

  • Je ne pense pas que des décisions seront prises, le but est de discuter, s'organiser et échanger.
  • La thématique est le back mais tout le monde peut venir. Simplement la discussion devra plus porter sur du Django que du Html.

C'est jamais bon de faire une réunion sans ordre du jour.

Pour le caractère "non public" de Skype, je ne pense pas que SF prétentai que vous preniez des décisions en société secrète, mais simplement que, contrairement à ce que sous entendais Alex, vos discussions privés ne peuvent pas être considéré comme équivalente (privée, uniquement pour vous 2) et que donc si il serait peut etre bien de faire le même genre de reunion pour le front.

+3 -0
Staff

Pour le caractère "non public" de Skype, je ne pense pas que SF prétentai que vous preniez des décisions en société secrète, mais simplement que, contrairement à ce que sous entendais Alex, vos discussions privés ne peuvent pas être considéré comme équivalente (privée, uniquement pour vous 2) et que donc si il serait peut etre bien de faire le même genre de reunion pour le front.

Kje

C'est exactement ça.

Tu devais pas nous faire une doc avant ? Tu nous as dit toi même que tu en aurais pas pour longtemps.

Il faut de la motivation, et en ce moment je n'ai pas la motivation d'écrire des pavés, mais ça viendra soon + bientôt + à venir. En fait, vu qu'on fait des modifs en ce moment sur les dépendances et autres, il faut encore que je repasse sur le sprite @1x avant d'arriver au code stable v1.

Enfin bref, on part en HS. Mais en somme je pense qu'on fera un tour avec sandhose quand même.

Staff

Voici les logs :

[2014-08-28 20:01:09] <firm1> Le principe est simple, l'idée est de faire un petit point avant la rentrée (de début des activités quoi)
[2014-08-28 20:01:17] <Eskimon> plop
[2014-08-28 20:01:29] <artragis> . <= un petit point
[2014-08-28 20:01:37] <firm1> haha
[2014-08-28 20:01:58] <firm1> Globalement l'ordre du jour est ici : http://zestedesavoir.com/forums/sujet/1095/un-zestmeeting/?page=1#p19162
[2014-08-28 20:02:12] <firm1> l'idée est d'aller point par point
[2014-08-28 20:02:32] <Sandhose> "Les premiers arrivés auront des cookies" ? Ca me va
[2014-08-28 20:02:33] <firm1> si on est éfficace on devrait avoir fini en moins de 2h (artragis le pauvre)
[2014-08-28 20:02:39] * Nodraak1 (Nodraak@Smooth-krt45g.rev.sfr.net) vient de rentrer
[2014-08-28 20:02:51] <artragis> (pk le pauvre?)
[2014-08-28 20:03:05] <Sandhose> artragis: C'pas toi qui doit partir tot ?
[2014-08-28 20:03:11] <pierre_24> tu devais pas partir en vac' ?
[2014-08-28 20:03:12] <firm1> artragis: tu voulais le faire assez tot je crois
[2014-08-28 20:03:16] <firm1> d'ou le pauvre
[2014-08-28 20:03:18] * Nodraak a quitté (Ping timeout: 121 seconds)
[2014-08-28 20:03:27] * Akulen a donné le statut d'opérateur de canal à Nodraak1
[2014-08-28 20:03:28] <firm1> Aie et Nodraak1a des soucis
[2014-08-28 20:03:30] <artragis> ah, oui, en fait je fais des choses en même temps
[2014-08-28 20:03:43] <Nodraak1> ouai mon wifi a bug-é
[2014-08-28 20:03:43] <artragis> mais en gros je pourrais quand même voir ce que vous dites
[2014-08-28 20:03:49] <firm1> ah ok
[2014-08-28 20:04:08] <firm1> Bon reprenons alors
[2014-08-28 20:04:25] <pierre_24> Les cookies, donc …
[2014-08-28 20:04:40] <pierre_24> … Euh, la doc
[2014-08-28 20:05:05] <firm1> Pour pas qu'on s'emmele dans nos idées, je propose que tout le monde ne parle pas en meme temps
[2014-08-28 20:05:17] <firm1> il suffit de dire "je prend" pour prendre la parole
[2014-08-28 20:05:29] <firm1> et "j'ai fini" pour la donner a quelqu'un d'autre
[2014-08-28 20:05:32] <firm1> ça vous va ?
[2014-08-28 20:05:46] <Akulen> je prend oui j'ai fini
[2014-08-28 20:05:53] <Sandhose> je prends — yep yep — j'ai fini
[2014-08-28 20:06:05] <SpaceFox> je prends bof ça me parait super compliqué essayons sans pour voir j'ai fini
[2014-08-28 20:06:14] <Nodraak1> je prend ca va etre autant le borderl - jai fini
[2014-08-28 20:06:18] <firm1> je prends
[2014-08-28 20:06:21] <firm1> Ok, ok
[2014-08-28 20:06:28] <firm1> parlons du point 1
[2014-08-28 20:06:34] <firm1> La documentation
[2014-08-28 20:06:52] <firm1> On a eu pas mal de reproches la dessus
[2014-08-28 20:07:04] <firm1> on a évoqué pas mal de solution aussi sur le ticket
[2014-08-28 20:07:13] <artragis> (link stp?)
[2014-08-28 20:07:42] <firm1> cette issue principalement : https://github.com/zestedesavoir/zds-site/issues/1350
[2014-08-28 20:08:07] <firm1> certiains ont évoqué des outils comme une VM, ou un Docker, etc.
[2014-08-28 20:08:28] <firm1> pour vous, y'a t-il de gros manque dans notre doc aujourd'hui ?
[2014-08-28 20:08:32] <firm1> j'ai fini
[2014-08-28 20:08:47] <SpaceFox> Pour moi oui, mais pas le message que tu linkes
[2014-08-28 20:09:15] <pierre_24> https://github.com/zestedesavoir/zds-site/issues/1356 ?
[2014-08-28 20:09:17] <SpaceFox> la doc d'install on a pas mal bossé dessus, mais maintenant on a quelque chose d'installable par à peu près n'importe quel dev (j'insiste : "dev") intéressé par le projet
[2014-08-28 20:09:26] <SpaceFox> par contre on a un vrai problème avec ce genre de situation : https://github.com/zestedesavoir/zds-site/issues/1385#issuecomment-53558150
[2014-08-28 20:09:53] <firm1> la tu parle du front SpaceFox
[2014-08-28 20:09:54] <pierre_24> Mmmh, ça c'est la doc' du front
[2014-08-28 20:09:56] <SpaceFox> là c'est le front, mais ça arrive aussi sur le back : on se retrouve face à des cas non documentés qu'il faut expliquer au dev
[2014-08-28 20:09:58] <firm1> c'est plutot celle ci : https://github.com/zestedesavoir/zds-site/issues/1356
[2014-08-28 20:10:06] <Nodraak1> je prend
[2014-08-28 20:10:25] <Nodraak1> - doc install : tout est eparpillé : win mac linux : utile ?
[2014-08-28 20:10:34] <Sandhose> Qu'en est-il de la doc dans le code ? J'veux dire, j'ai pas spécialement regardé le code du back, mais est-ce que chaque fonction est commentée ?
[2014-08-28 20:10:39] <SpaceFox> mon exemple était un exemple, valable pour le front et le back ; ce qu'il est important de documenter, c'est ce qui n'est PAS standard
[2014-08-28 20:11:15] <SpaceFox> à commencer par toute la gestion des tutos, c'est ce qui est à la fois complexe et custom
[2014-08-28 20:11:16] <Nodraak1> - doc back : par exemple https://github.com/zestedesavoir/zds-site/issues/1173 (com de fim1)
[2014-08-28 20:11:28] <Nodraak1> (jai fini)
[2014-08-28 20:11:44] <firm1> tout a fait Nodraak1 je cherchais ce lien
[2014-08-28 20:12:01] <firm1> Je prends (et j'insiste)
[2014-08-28 20:12:05] <SpaceFox> <Nodraak1> - doc install : tout est eparpillé : win mac linux : utile ? –> Oui, parce que les procédures sont très différentes
[2014-08-28 20:12:06] <Sandhose> De plus, si on commence à documenter le code de manière stricte (avec des "@param", "@return" et tout dans des blocs de commentaire pour chaque fonciton, il existe des outils ensuite pour générer une doc html
[2014-08-28 20:12:15] <firm1> Pour moi on a plusieurs type de documentation
[2014-08-28 20:12:26] <firm1> la doc d'install (plutot bonne selon les retours)
[2014-08-28 20:12:31] <SpaceFox> Sandhose> d'abord le "quoi", ensuite le "comment"
[2014-08-28 20:12:32] <firm1> La doc du back-end en lui meme
[2014-08-28 20:12:48] <Nodraak1> spacefox je suis aps sur, jai galere a rgrouper chaque morceau a installer
[2014-08-28 20:12:51] <firm1> une grosse partie de la doc fonctionnelle des tutos est ici : http://zestedesavoir.com/forums/sujet/766/etat-de-lart-du-module-des-tutoriels/
[2014-08-28 20:13:31] <firm1> on ne doit pas mélanger les deux types de doc
[2014-08-28 20:13:42] <firm1> pour ce qui est de la doc back
[2014-08-28 20:13:55] <firm1> je pensais à faire un truc basé sur sphinx
[2014-08-28 20:14:08] <firm1> http://sphinx-doc.org/
[2014-08-28 20:14:18] <firm1> une sorte de javadoc pour python
[2014-08-28 20:14:35] <firm1> qui sert a génerer la doc automatiquement
[2014-08-28 20:14:38] <firm1> J'ai fini
[2014-08-28 20:14:58] <SpaceFox> ok pour la technique, mais il reste le problème du fonctionnel (à rappatrier sur le dépôt)
[2014-08-28 20:15:18] <firm1> Est-ce que la doc fonctionnelle doit être sur le dépot ?
[2014-08-28 20:15:20] <SpaceFox> Nodraak1> pour moi on peut en parler en privé, mais c'est un détail, et si tu as du aller voir en même temps les docs d'install sur plusieurs OS c'est qu'il y a un problème
[2014-08-28 20:15:38] <SpaceFox> oui, la doc foncitonnelle doit être sur le dépôt, pour comprendre ce que fait le produit
[2014-08-28 20:15:56] <Eskimon> firm1, une doc "d'entete' dans chaque module me semble la bienvenue
[2014-08-28 20:15:57] <pierre_24> Moi, je suis d'accord avec Spacefox
[2014-08-28 20:16:12] <SpaceFox> je mange des produits avec une pure doc technique pas détaillée tous les jours, c'est infernal
[2014-08-28 20:16:44] <pierre_24> De manière générale, y'a pas de "guidelines" sur les commentaires. Certaines fonctions sont documentées, d'autre pas …
[2014-08-28 20:16:53] <artragis> Je propose une chose :
[2014-08-28 20:17:27] <artragis> sur le modèle de ce qui se faisaient à l'époque pour php (le langage, pas les framework), quand une personne modifie une fonction, elle s'assure de :
[2014-08-28 20:17:28] <firm1> Il faut bien comprendre que si on décide d'inclure une doc fonctionnelle dans le module, il faudrait vérifier que cette doc est mise à jour a chaque modification/ajout de nouvelle features. Et on sait bien que plus une doc est énorme, plus elle est imbuvable. Et le crontributeurs lambda aura cette contrainte en plus.
[2014-08-28 20:17:35] <firm1> Est-ce que c'est ce que l'on veut ?
[2014-08-28 20:17:40] <artragis> - la présence d'une doc complète (technique + fonctionnelle + exemples)
[2014-08-28 20:17:48] <artragis> - totalement pep8
[2014-08-28 20:18:14] <pierre_24> (pep, c'est pour plus tard dans la réunion :p )
[2014-08-28 20:18:46] <pierre_24> firm1: objectivement, oui, c'est ce que je préférerai
[2014-08-28 20:19:43] <Sandhose> @firm1 Pour moi il y a la doc technique qui documente chaque fonction, générée par Sphinx, et la doc rédigée "a la main" sur le Wiki
[2014-08-28 20:19:50] <SpaceFox> firm1> d'accord, c'est super chiant. Mais une doc fonctionnelle est indispensable pour qu'on puisse comprendre l'application. Ca évite 1. de développer des trucs délirants fonctionnellements par mégarde et 2. de ne pas avoir à comprendre le code pour savoir ce qu'il fait et POURQUOI il le fait
[2014-08-28 20:19:53] <firm1> En sachant que le contributeurs aujourd'hui on lui demande 1/ Installer le bousin 2/ faire une modification 3/ faire une PR 4/faire des notes pour la QA 5/ ajouter des tests 6/ mettre a jour la doc de ses modifs
[2014-08-28 20:20:10] <SpaceFox> Comme tout projet open-source, non ?
[2014-08-28 20:20:23] <firm1> Je trouve quand meme qu'on commence a demander un peu trop au contributeurs lambda
[2014-08-28 20:20:31] <SpaceFox> Ah on peut toujours l'aider
[2014-08-28 20:20:44] <SpaceFox> mais si on ne le fait pas, dans 1 an on a un truc incompréhensible.
[2014-08-28 20:20:52] <firm1> Oui mais est-ce que quelqu'un aide quiconque a faire des notes de QA ?
[2014-08-28 20:20:53] <SpaceFox> en fait non : on a DEJA un truc en partie incompréhensible
[2014-08-28 20:21:07] <SpaceFox> c'est déjà arrivé pour les notes de QA
[2014-08-28 20:21:12] <SpaceFox> sur une PR de gashe de mémoire
[2014-08-28 20:21:28] <firm1> oui mais combien sont pret a le faire
[2014-08-28 20:21:31] <firm1> ?
[2014-08-28 20:21:36] <pierre_24> Moi :p
[2014-08-28 20:21:40] <SpaceFox> ce n'est pas la question firm1
[2014-08-28 20:21:44] <SpaceFox> le fait est qu'on DOIT le faire
[2014-08-28 20:22:00] <SpaceFox> quitte à accepter des docs de 2 lignes si ça suffit
[2014-08-28 20:22:16] <firm1> Je n'ai pas d'avis tranché hein, je veux juste qu'on comprenne les impact de ce qu'on décide. Si on fait une doc fonctionnelle sur le dépot elle doit être maintenu, testée, etc.
[2014-08-28 20:22:27] <Eskimon> Surtout que ca peut se faire dans la periode de QA, de maniere communautaire
[2014-08-28 20:22:53] <pierre_24> On a déjà vu ce que ça donnais d'écrire "oubliez pas pep8" sans le vérifier. Si on insiste pas desssus, ce sera pas fait
[2014-08-28 20:22:53] <SpaceFox> D'ailleurs la doc fonctionnelle aide la QA : elle permet de savoir ce qu'il y a à tester (ce que c'est sensé faire)
[2014-08-28 20:23:19] <firm1> SpaceFox: lol non
[2014-08-28 20:23:45] <firm1> 'fin pour avancer, on est donc d'accord sur le fait qu'on documente dès que possible le fonctionnel du site ?
[2014-08-28 20:23:52] <firm1> Ceci est une demande de vote :)
[2014-08-28 20:23:57] <pierre_24> Pour !
[2014-08-28 20:23:59] <SpaceFox> firm1> sisi, la moitié de mes notes de QA c'est une bête description fonctionnelle de la fonctionnalité
[2014-08-28 20:24:04] <SpaceFox> Pour
[2014-08-28 20:24:19] <artragis> Pour
[2014-08-28 20:24:19] <Hugo> Pour
[2014-08-28 20:24:27] <Akulen> pour, mais ca serait une bonne idee de faire une sorte de guide pour indiquer au nouveau contributeur ce qu'il a a faire
[2014-08-28 20:24:31] <Florian> Pour également.
[2014-08-28 20:24:42] <firm1> Et donc qu'a partir d'aujourd'hui, chaque nouvelle PR doit être accompagnée d'une DOC ou d'une modficaition de la doc existante ?
[2014-08-28 20:24:47] <pierre_24> Je plussoie violement Akulen, si GH ou sur le fofo
[2014-08-28 20:24:58] <pierre_24> *sur
[2014-08-28 20:25:02] <firm1> Nice
[2014-08-28 20:25:07] <firm1> Avançons alors
[2014-08-28 20:25:26] <SpaceFox> Akulen> déjà fait : https://github.com/zestedesavoir/zds-site/blob/master/CONTRIBUTING.md
[2014-08-28 20:25:28] <Hugo> on fait quoi des commentaires existant ?
[2014-08-28 20:25:39] <SpaceFox> (GitHub l'affiche dès que tu demande une PR)
[2014-08-28 20:25:43] <Akulen> SpaceFox> un peu plus detaillee
[2014-08-28 20:25:56] <Akulen> j'ai du recolter les morceaux un peu partout la premiere foix
[2014-08-28 20:25:59] <pierre_24> SpaceFox: y'a pas "comment faire une note de QA"
[2014-08-28 20:25:59] <SpaceFox> Akulen> bien sûr, on peut améliorer
[2014-08-28 20:26:21] <firm1> Avançons, les amis, on est a la bourre
[2014-08-28 20:26:28] <firm1> ;)
[2014-08-28 20:26:36] <firm1> On a pas parlé des dépendances du projet
[2014-08-28 20:26:46] <firm1> Y'a t-il des trucs a faire dessus ?
[2014-08-28 20:26:51] <firm1> d'après vous ?
[2014-08-28 20:26:51] <pierre_24> Note ça quelque part quand même, et movin' on :p
[2014-08-28 20:27:12] <SpaceFox> (je crée une issue pour le contributing)
[2014-08-28 20:27:23] <pierre_24> Oui, ajouter clairement qu'une PR DOIT contenir une note de QA, et comment écrire ça en gros
[2014-08-28 20:27:38] <pierre_24> (1. Qu'est ce que ça change 2. Comment reproduire)
[2014-08-28 20:27:45] <firm1> +1
[2014-08-28 20:28:00] <artragis> +1
[2014-08-28 20:28:21] <firm1> J'ai mentionné les dépendances du projet
[2014-08-28 20:28:21] <pierre_24> Quitte à formaliser ça avec un machin obligatoire comme le tableau de toutes les PRs
[2014-08-28 20:28:39] <firm1> coté back-end la majoirté des trucs obligatoire passe par pip
[2014-08-28 20:28:57] <artragis> sauf les font ms il me semble
[2014-08-28 20:28:59] <firm1> y'a des truc comme pandoc ou latex qui passe par haskell
[2014-08-28 20:29:14] <firm1> là on parle juste de back
[2014-08-28 20:29:19] <SpaceFox> LE truc chiant quand on veut un ZdS complet, c'est récupérer les centaines de Mo juste pour pandoc (je crois)
[2014-08-28 20:29:27] <Sandhose> firm1: On a fait notre possible pour le front, on a plus que node réellement comme dépendance :)
[2014-08-28 20:29:43] <firm1> Sandhose: tkt, on parle pas de front ici
[2014-08-28 20:29:46] <firm1> :)
[2014-08-28 20:30:04] <firm1> SpaceFox: oui, et donc pour palier au problème de Haskell pour pandoc
[2014-08-28 20:30:07] <Sandhose> Sinon, tu pense par rapport au nombre de choses à faire, ou au poids des dépendances ?
[2014-08-28 20:30:34] <pierre_24> Pandoc comprend aussi l'énorme (!) LaTeX
[2014-08-28 20:30:35] <firm1> Il faudrait stocker les binaires pandoc
[2014-08-28 20:30:57] <firm1> actuellement par exemple travis ne compile plus le haskell
[2014-08-28 20:31:04] <firm1> il se contente de télécharger le binaire pandoc
[2014-08-28 20:31:12] <firm1> sur le dropbox de Eskimon
[2014-08-28 20:31:14] <firm1> :)
[2014-08-28 20:31:25] <Sandhose> Parce que pendant mes tests avec Docker, j'ai vu qu'on avait en gros \80Mb de dépendance (je suis pas sur si ca inclut python/node) sans pandoc, et \850Mb avec
[2014-08-28 20:31:25] <firm1> parce que Eskimon la compilé pour ubuntu 12.04
[2014-08-28 20:31:50] <pierre_24> Sandhose: on en a déjà parlé, mais j'était pas d'accord avec tes chiffres :p
[2014-08-28 20:32:00] <firm1> on pourrait mettre a disposition des version compilée de pandoc pour alleger
[2014-08-28 20:32:07] <firm1> mais Latex on peut pas s'en passer
[2014-08-28 20:32:08] <SpaceFox> c'est pas un truc qui est dans les dépôts pour les env Linux ?
[2014-08-28 20:32:33] <firm1> Les dépots ubuntu < 12.04 n'ont pas la version 1.10 de pandoc
[2014-08-28 20:32:38] <pierre_24> firm1: on peut se passer de LaTeX pour les pdfs ?
[2014-08-28 20:32:44] <Sandhose> pierre_24: Donc je pense que c'est ~80Mb hors Node et Python
[2014-08-28 20:32:46] <firm1> nous on a besoin de la version 1.10 minimum de pandoc
[2014-08-28 20:32:48] <SpaceFox> OSEF Ubuntu < 12.04
[2014-08-28 20:32:50] <SpaceFox> non ?
[2014-08-28 20:32:54] <pierre_24> Exactement
[2014-08-28 20:33:03] <pierre_24> elle est quasi hors-support
[2014-08-28 20:33:30] <firm1> Euh … je vous rappelle que debian non plus n'a pas les bonnes versions hein
[2014-08-28 20:33:43] <firm1> et je suis meme pas sur que ubuntu 13.04 soit a jour a ce niveau
[2014-08-28 20:34:10] <SpaceFox> y'a quoi dans cette 1.10 qui nous est indispensable ?
[2014-08-28 20:34:14] <Sandhose> Sinon, est-ce qu'on a de réels tests qui vérifient le boulot de pandoc ? Parce que pour travis, on pourrait juste désactiver la génération du PDF, et donc raccourcir le temps de build…
[2014-08-28 20:34:33] <firm1> "Y''a quoi dans cette 1.10 qui nous est indispensable ?" => des variables
[2014-08-28 20:35:06] <SpaceFox> OK, donc du vraiment indispensable
[2014-08-28 20:35:12] <SpaceFox> du coup, voilà ce que je propose
[2014-08-28 20:35:12] <firm1> Sandhose: ce n'est pas travis la génération du pdf qui epuise travis
[2014-08-28 20:35:23] <firm1> travis n'est meme pas epuisé en fait
[2014-08-28 20:35:29] <firm1> c'était pire avant
[2014-08-28 20:35:36] <Sandhose> firm1: Mais je pensais surtout par rapport au téléchargement de pandoc + latex
[2014-08-28 20:35:42] <firm1> bref, c'est une solution pour les devs qu'on cherche la
[2014-08-28 20:35:43] <SpaceFox> pour 90% des devs, ce truc est inutile. C'est un besoin quand on doit toucher Pandoc ou pour une version en prod
[2014-08-28 20:36:15] <firm1> "pour 90% des devs, ce truc est inutile. C'est un besoin quand on doit toucher Pandoc ou pour une version en prod" => c'est pour ça que PANDOC est marqué dans la partie OPTIONNELLE
[2014-08-28 20:36:20] <firm1> Personne n'est obligé de l'installer
[2014-08-28 20:36:46] <SpaceFox> ui mais ajouter une instruction d'installation du genre "utilisez la version de votre distribution si elle est >= 1.10, sinon faites gaffe ça va prendre 800 Mo"
[2014-08-28 20:37:03] <pierre_24> +1 pour SpaceFox
[2014-08-28 20:37:41] <firm1> SpaceFox: si on laisse des pièges dans la doc, ça fini par devenir trop gros
[2014-08-28 20:37:48] <SpaceFox> ?
[2014-08-28 20:38:04] <Eskimon> +1 pour firm1 , je trouve la phrase de SpaceFox pas clair
[2014-08-28 20:38:20] <firm1> si tu installe pandoc via tes dépots, et que tu essaye ensuite de l'installer à la main, tu as interet a t'accrocher
[2014-08-28 20:38:33] <SpaceFox> ah parce qu'en plus c'est un logiciel merdique de ce genre ?
[2014-08-28 20:38:34] <SpaceFox> >_<
[2014-08-28 20:38:49] <firm1> Voila, c'était le troll sur Haskell
[2014-08-28 20:38:52] <firm1> ;)
[2014-08-28 20:38:54] <SpaceFox> J'ai trop l'habitude des machins en Java moi…
[2014-08-28 20:39:18] <SpaceFox> bon ben va pour "on a besoin de la version 1.10, voilà comment l'installer à la main mais ça va vous prendre > 800 Mo"
[2014-08-28 20:39:36] <SpaceFox> Quant au reste des dépendances, on a une tâche qui est de les rationnaliser (on en a qui sont à priori inutiles) et de fixer les numéros de version de celles qui sont toujours en "dernière version dispo"
[2014-08-28 20:39:46] <SpaceFox> les 2 sont déjà sur GH
[2014-08-28 20:39:52] <firm1> On peut aussi collecter tous les binaire pandoc pour pleins de plateformes, et les mettre à disposition
[2014-08-28 20:39:57] <firm1> Il suffit de les compiler
[2014-08-28 20:40:04] <firm1> pour chaque distribution
[2014-08-28 20:40:10] <SpaceFox> firm1> vu l'utilité en dev, je pense que c'est une perte de temps
[2014-08-28 20:40:11] <pierre_24> firm1: j'ai peur que ça sorte du cadre de zds
[2014-08-28 20:40:21] <SpaceFox> c'eut été un élément indispensable (genre la lib git), OK
[2014-08-28 20:40:34] <firm1> ça roule
[2014-08-28 20:40:45] <firm1> donc on fait rien a ce niveau
[2014-08-28 20:40:50] <firm1> on avance comme ça
[2014-08-28 20:41:18] <firm1> Et pensez a rappeler aux nouveaux contributeurs qui tente d'installer pandoc sans succès que c'est FACULTAIF
[2014-08-28 20:41:47] <pierre_24> Oh, en général ils y arrivent :p
[2014-08-28 20:41:56] <firm1> Next POINT : Le ZestFLOW
[2014-08-28 20:41:57] <pierre_24> peut-être éclaircir les docs correspondantes ?
[2014-08-28 20:42:11] <firm1> ok pierre_24 c'est noté
[2014-08-28 20:42:25] <firm1> parlons du zestflow maintenant : http://zestedesavoir.com/forums/sujet/445/modele-de-branches/?&page=4#p12568
[2014-08-28 20:42:46] <Eskimon> yeah le zestflow !
[2014-08-28 20:42:49] <firm1> Je suppose que tout le monde a lu
[2014-08-28 20:43:01] <pierre_24> Pitié, pas encore une discution interminable sur quel branche employer à quel moment et des gens qui ne se lisent pas …
[2014-08-28 20:43:05] <SpaceFox> ou carrément ici en fait : https://github.com/zestedesavoir/zds-site/pull/1395
[2014-08-28 20:43:07] <firm1> et que ça convient a tout le monde
[2014-08-28 20:43:35] <Akulen> en fait j'ai pas eu le temps de lire, je peux avoir un petit resume si c'est possible ?
[2014-08-28 20:43:45] <firm1> haha pierre_24 non c'est juste pour valider ce point
[2014-08-28 20:44:00] <firm1> Akulen: ça va être dificile de resumer ça
[2014-08-28 20:44:08] <firm1> tu peux regarder le lien de SpaceFox ci-dessus
[2014-08-28 20:44:13] <SpaceFox> Akulen> "Git flow" sans la remontée permanence des correctifs de la branche de release et des rbranches renommées
[2014-08-28 20:44:13] <firm1> c'est plus claire
[2014-08-28 20:44:14] <Akulen> pg alors, je rattraperais apres
[2014-08-28 20:44:36] <firm1> Next POINT : la QA !
[2014-08-28 20:44:47] <firm1> Est-ce que tout va bien de ce coté ?
[2014-08-28 20:45:03] <pierre_24> Ben du coup, avec un "comment faire une QA", ça va, me semble
[2014-08-28 20:45:23] <SpaceFox> on manque pas mal de QA il me semble
[2014-08-28 20:45:26] <pierre_24> faudrait juste plus de "type à QA", mais bon ^^
[2014-08-28 20:45:33] <firm1> ouaip bien vu, vous être en avance lol
[2014-08-28 20:45:44] <Nodraak1> zest flow : en gros, en temps que dev je clone la branch dev et je push ma branch ?
[2014-08-28 20:45:48] <SpaceFox> même si en ce moment c'est délicat parce qu'il faudrait que la v1.0 soit mergée pour pouvoir avancer vraiment (et faire des QA propres)
[2014-08-28 20:46:24] <pierre_24> Justement, pour le passage en V1.0, faudrait un coup de préprod' avant
[2014-08-28 20:46:28] <firm1> Concernant la QA, je trouve qu'on exploite pas assez notre preprod.
[2014-08-28 20:46:39] <firm1> tu lis dans mes penses
[2014-08-28 20:46:40] <pierre_24> on l'as récupérée ?
[2014-08-28 20:46:43] * hexahel (20350f17467@Smooth-qobqsd.net) vient de rentrer
[2014-08-28 20:46:44] <SpaceFox> firm1> le ZestFlow est là pour ça :)
[2014-08-28 20:46:47] <firm1> La QA est hop depuis
[2014-08-28 20:47:34] <pierre_24> "hop" ?
[2014-08-28 20:47:41] <firm1> /hop/up
[2014-08-28 20:47:56] <firm1> /s/hop/up
[2014-08-28 20:48:26] <firm1> donc en gros, la QA vousne roulez pas sur l'or, mais ça va bien quand même. J'ai bon ?
[2014-08-28 20:49:18] <artragis> le mot de passe de la preprod a changé
[2014-08-28 20:49:21] <pierre_24> On suis, quoi :p
[2014-08-28 20:49:21] <Eskimon> Perso a mes yeux pour la QA tout roule. Tant que les gens continue a etre diplomatique, patient et a l'ecoute les uns des autres c'est super !
[2014-08-28 20:49:23] <artragis> je peux plus y accéder
[2014-08-28 20:49:34] <pierre_24> +1 pour artragis (je viens d'essayer aussi)
[2014-08-28 20:49:46] <pierre_24> et +1 pour Eskimon
[2014-08-28 20:49:59] <firm1> y'a des truc a faire sur la preprod alors, je note ça
[2014-08-28 20:50:11] <firm1> mais ça semble bon.
[2014-08-28 20:50:19] <SpaceFox> je peux balancer le mot de passe préprod ici ?
[2014-08-28 20:50:19] <pierre_24> Faudrait refaire un appel à contribution. Chaipa trop comment, mais ça serait nice
[2014-08-28 20:50:38] <Nodraak1> contributrion pour ? etre de la QA ?
[2014-08-28 20:50:41] <SpaceFox> allez je suis fou, au pire on le changera
[2014-08-28 20:50:41] <firm1> Appel a contribution, aussi c'est noté
[2014-08-28 20:50:45] <artragis> je propose que cet appel se fasse au moment où la v1 sera officiellement annoncée
[2014-08-28 20:50:54] <pierre_24> Par exemple, oui
[2014-08-28 20:51:03] <pierre_24> (et oui, contrib' pour QA)
[2014-08-28 20:51:34] <firm1> Bon, Next point : Les modules sensibles !
[2014-08-28 20:51:49] <firm1> Là j'ai mentionné les tutoriels
[2014-08-28 20:52:00] <firm1> car actuellement c'est le truc assez critique
[2014-08-28 20:52:11] <firm1> qui nous fou des erreur 500 un matin a 6h
[2014-08-28 20:52:18] <pierre_24> Et tu cherches à ce qu'on arrive à quoi, avec ce point ?
[2014-08-28 20:52:23] <artragis> il en fait encore?
[2014-08-28 20:52:24] <firm1> il faut vachement faire attention a ça pendant les QA !
[2014-08-28 20:52:44] <firm1> non, juste attirer l'attention coté QA sur ça
[2014-08-28 20:52:51] <artragis> ça me va
[2014-08-28 20:53:01] <firm1> j'ai vu passer des PR par exemple qui ouvrait des brèches
[2014-08-28 20:53:10] <artragis> et j'ai la vague impression que ce module ne va pas trop avoir de correction jusqu'aux zep 8 et 12?
[2014-08-28 20:53:31] <firm1> on verra oui
[2014-08-28 20:53:57] <pierre_24> Ben les bugs critiques, faut quand même les régler
[2014-08-28 20:53:59] <firm1> J'en profite aussi pour préciser les liens entre tuto, articles et gallerie
[2014-08-28 20:54:32] <firm1> chaque PR qui passe sur un des modules ci-dessus doit être bien vérifiée avec ses modules adjacents
[2014-08-28 20:54:44] <SpaceFox> <firm1> j'ai vu passer des PR par exemple qui ouvrait des brèches –> définis "brèches" ?
[2014-08-28 20:55:07] <firm1> quand je parle de brèches, je parle d'un fix qui ouvre une faille ailleurs
[2014-08-28 20:55:22] <SpaceFox> faille = sécurité ?
[2014-08-28 20:55:31] <firm1> faille qui crée des 500
[2014-08-28 20:55:38] <firm1> ou des mdofications de structures
[2014-08-28 20:55:46] <SpaceFox> OK
[2014-08-28 20:55:58] <firm1> depuis qu'on est en prod, il faut a chaque PR penser à l'existant
[2014-08-28 20:56:00] <SpaceFox> si c'est détecté, la PR doit être complètement bloquée jusu'à correction
[2014-08-28 20:56:16] <pierre_24> ça me semble logique
[2014-08-28 20:56:20] <firm1> le truc c'est qu'on ne pense pas toujours aux tutos existants
[2014-08-28 20:56:29] <firm1> et souvent pas c'est pas testé
[2014-08-28 20:56:41] <artragis> c'est pour ça qu'il faut une préprod
[2014-08-28 20:56:58] <firm1> ouaip
[2014-08-28 20:57:11] <SpaceFox> A ce sujet
[2014-08-28 20:57:11] <firm1> on dira donc qu'ici le plan d'action d'amélioration sera la preprod
[2014-08-28 20:57:34] <SpaceFox> 1. on a un outil qui s'appelle Sentry qui permet de détecter ces erreurs. Par contre il donne des tonnes d'infos personnelles donc je ne peux pas ouvrir les accès à tous le sdevs
[2014-08-28 20:57:40] <SpaceFox> 2. Il est branché sur la préprod
[2014-08-28 20:58:38] <SpaceFox> Bon ça a l'air bon pour tout le monde, firm1 il reste des sujets ?
[2014-08-28 20:58:44] <firm1> Sauf que les truc du style l'auteur qui te signale après la MEP que la moitié de son historique de tuto ne fonctionne plus … Sentry ne te le diras pas
[2014-08-28 20:58:57] <firm1> Bref, Next POINT
[2014-08-28 20:59:03] <firm1> La qualité du code
[2014-08-28 20:59:03] <SpaceFox> non, mais ça permet de détecter des erreurs qu'on aurait jamais vu sinon
[2014-08-28 20:59:25] <firm1> Qui pour une passage hebdomadaire de PEP8 ? :)
[2014-08-28 20:59:40] <SpaceFox> pour la PEP8 je serais carrément pour l'intégrer à Travis
[2014-08-28 20:59:44] <SpaceFox> mais je sais pas si c'est faisable
[2014-08-28 20:59:45] <firm1> On l'impose finalement cette PEP8 ou pas ?
[2014-08-28 20:59:45] <pierre_24> Sans dec', je pense que pour la V1, le code doit à nouveau Pep8
[2014-08-28 21:00:00] <SpaceFox> si c'est faisable, il faut qu'on fasse un passage PEP8 d'abord
[2014-08-28 21:00:03] <pierre_24> comme ça, on repart dessus, et oui, on impose ê⁸
[2014-08-28 21:00:03] <Sandhose> firm1: On devrait pas inciter les gens à mettre des hooks de pre-commit qui vérifient ca au moment du commit ?
[2014-08-28 21:00:20] <SpaceFox> alors, pour la v1.0, je vais faire une parenthèses là-dessus
[2014-08-28 21:00:30] <SpaceFox> fonctionnellement, on est en v1.0 depuis l'ouverture
[2014-08-28 21:00:31] <firm1> C'est possible de bloquer sur travis le code non PEP-8, donc on va faire ça
[2014-08-28 21:00:50] <firm1> Donc ça c'est bon
[2014-08-28 21:00:56] <SpaceFox> la milestone v1.0 elle est là pour avoir du code suffisemment stable pour pouvoir commencer le zestflow
[2014-08-28 21:00:56] <pierre_24> firm1: si on fait ça maintenant, plus rien passe :p
[2014-08-28 21:01:02] <firm1> Je me réserve de faire cette action
[2014-08-28 21:01:03] <Sandhose> A noter que la build bloque quand le code n'est pas confrme à JSHint coté front :p
[2014-08-28 21:01:15] <firm1> ouaip Sandhose
[2014-08-28 21:01:24] <SpaceFox> et c'est URGENT aujourd'hui de la terminer, on a 9 PR qui attendent qu'on passe au zestflow
[2014-08-28 21:01:24] <Eskimon> +1 pour imposer pep-8, et 1 pour le hook de précommit, sinon c'est clair et net on va se prendre des paquets de commit "Fix PEP8"
[2014-08-28 21:01:30] <firm1> pierre_24: je penserais a tout PEP8ser avant
[2014-08-28 21:01:41] <pierre_24> firm1: définitivement pour
[2014-08-28 21:01:44] <SpaceFox> donc, on ne rajoute RIEN à la v1.0
[2014-08-28 21:01:51] <Sandhose> D'ailleurs, y'a aussi des outils de lint pour SCSS et autre… Je verrais avec Alex pour mettre ca en place
[2014-08-28 21:01:52] <firm1> ouaip SpaceFox
[2014-08-28 21:02:12] <firm1> Next POINT
[2014-08-28 21:02:18] <firm1> le refactoring
[2014-08-28 21:02:23] <SpaceFox> d'ailleurs, pour limiter les conflits, il faudrait activer la pep-8 un jour où y'a pas trop de PR en cours
[2014-08-28 21:02:23] <firm1> je résume
[2014-08-28 21:02:41] <firm1> Nos fichiers sont énormes
[2014-08-28 21:02:45] <firm1> surtout les vues
[2014-08-28 21:02:58] <firm1> il faudrait les découpers en petit morceaux
[2014-08-28 21:03:07] <firm1> factoriser des trucs
[2014-08-28 21:03:13] <Nodraak1> peut on couper un views.py en deux ou trois fichiers proprement ?
[2014-08-28 21:03:20] <firm1> Nodraak1: oui
[2014-08-28 21:03:30] <pierre_24> Nodraak1: oui, c'est déjà parfois le cas
[2014-08-28 21:03:51] <firm1> par contre il faut le mettre dans une issue ça
[2014-08-28 21:03:59] <SpaceFox> firm1> je crée
[2014-08-28 21:04:04] <firm1> pour la refacto globale, je pense que les ZEP 8 et 12 sont là
[2014-08-28 21:04:19] <artragis> la 12 en particulier
[2014-08-28 21:04:23] <pierre_24> Ouaip', pour le module des tutos
[2014-08-28 21:04:25] <firm1> ouaip artragis
[2014-08-28 21:04:40] <SpaceFox> Oh je viens de découvrir un bug ! http://zestedesavoir.com/forums/sujet/927/enigme-a-resoudre/?page=6#p19173
[2014-08-28 21:04:45] <pierre_24> je traine pas trop dans les autres, peut-être qu'il y a de l'opti à faire par là
[2014-08-28 21:04:46] <firm1> A part ça, y'a d'autres bonnes pratiques qu'on a oublié ?
[2014-08-28 21:04:53] <artragis> on pourrait pas faire tourner des outils de métrique du code
[2014-08-28 21:05:04] <pierre_24> SpaceFox: c'est css, ça, nan ?
[2014-08-28 21:05:07] <artragis> qui permettrait de voir les endroits qui sont vraiment problématiques?
[2014-08-28 21:05:34] <firm1> artragis: metrique de code ? çad ?
[2014-08-28 21:05:51] <SpaceFox> pas besoin je pense
[2014-08-28 21:05:59] <SpaceFox> la métrique est simple : on a des fichiers .py de plus de
[2014-08-28 21:06:01] <SpaceFox> 3000 lignes
[2014-08-28 21:06:05] <Nodraak1> spacefox : le mot qui est pas coupé ? ya ca sur bcp (tout ?) de sites
[2014-08-28 21:06:16] <SpaceFox> Nodraak1> voilà
[2014-08-28 21:06:51] <firm1> bon allez, on avance si ça vous va
[2014-08-28 21:06:54] <firm1> Next POINT
[2014-08-28 21:07:06] <firm1> Optimisation du site
[2014-08-28 21:07:13] <pierre_24> artragis: rien n'empèche de le faire une fois pour voir ce que ça donne
[2014-08-28 21:07:18] <artragis> firm1 : c'est un ensemble d'analyse qui permettent de mettre en avant le couplage, le nombre de lignes etc
[2014-08-28 21:07:33] <firm1> ah ok artragis je connaissais pas
[2014-08-28 21:07:35] <artragis> ouai, je vais tenter de faire ça dès que les licences pycharm seront arrivées
[2014-08-28 21:07:43] <artragis> et qu'on aura une bonne intégration de tout ça
[2014-08-28 21:07:56] <firm1> n'héiste pas a créer un topic pour en parler
[2014-08-28 21:08:12] <pierre_24> tu fais comme les tests de firm1, tu balance (et commente) les résultats sur le fofo dev'
[2014-08-28 21:08:15] <artragis> un exemple : http://zestedesavoir.com/forums/sujet/548/comment-interpreter-les-metriques/
[2014-08-28 21:08:27] <artragis> je ferai ça pierre
[2014-08-28 21:08:35] <firm1> Cool
[2014-08-28 21:08:38] <firm1> NEXT alors
[2014-08-28 21:08:44] <firm1> L'optimisation du code
[2014-08-28 21:08:48] <firm1> les requetes SQL
[2014-08-28 21:09:01] <firm1> SpaceFox: t'as remarqué des requetes délirantes depuis sur Munin ?
[2014-08-28 21:09:12] <SpaceFox> alors, oui et non
[2014-08-28 21:09:15] <firm1> VOus avez remarqué des ralentissement chiants ?
[2014-08-28 21:09:19] <SpaceFox> je reprends mon graphe pour pas dire de conneries
[2014-08-28 21:09:39] <SpaceFox> JE vous fait l'intégrale en bref, tiens
[2014-08-28 21:09:53] <SpaceFox> - Le disque se remplit assez vite, on risque d'avoir un problème de taille un jour
[2014-08-28 21:09:56] <SpaceFox> (genre 1 anà
[2014-08-28 21:10:17] <pierre_24> firm1: y'avais pas quelqu'un qui était reparti pour optimiser plein de requetes ?
[2014-08-28 21:10:21] <SpaceFox> - ON se prends pas mal de requêtes SQL encore, mais ça reste sain : beaucoup de select simples
[2014-08-28 21:10:48] <artragis> tu peux pas poster les graph?
[2014-08-28 21:10:53] <firm1> pierre_24: je vois pas de qui tu parle
[2014-08-28 21:11:01] <firm1> SpaceFox: ok, nice alors
[2014-08-28 21:11:03] <SpaceFox> - ON a encore des requetes sans index (notées "slow queries" dans munin)
[2014-08-28 21:11:04] <Nicofuma> A propos du disque, tu sais ce qui prends le plus de place ? (évolue le plus vite)
[2014-08-28 21:11:20] <firm1> ce qui prend de la place je pense c'est clairement les images de tutos
[2014-08-28 21:11:30] <SpaceFox> Le principal problème des requêtes sans index, c'est qu'elles ne sont pas optimisables et ça le SGBD n'aime pas
[2014-08-28 21:11:38] <SpaceFox> ça l'oblige à créer des tables tempoeraires et tout
[2014-08-28 21:11:45] * Alex-D (AlexandreDe@Smooth-shrmj4.abo.wanadoo.fr) vient de rentrer
[2014-08-28 21:11:47] <SpaceFox> les graphes sont ici : http://munin.kisai.info/zestedesavoir.com/www.zestedesavoir.com/index.html
[2014-08-28 21:12:14] * Sandhose a donné la parole à Alex-D
[2014-08-28 21:12:22] <SpaceFox> quant au reste, on consomme encore pas mal de CPU mais ça c'est parce que j'ai l'habitude deprojets Java ET qu'on a AUCUN cache
[2014-08-28 21:12:24] <firm1> SpaceFox: tu pourrais nous faire une issue sur les requetes sans index ? Je pense que c'est assez simple a résoudre (suffit de rajouter l'attribut dans le modèle)
[2014-08-28 21:12:47] <pierre_24> SpaceFox: faut un mdp pour ton machin
[2014-08-28 21:12:57] <SpaceFox> firm1> il faut les identifier déjà, le pb est jsute là
[2014-08-28 21:13:02] <firm1> Les MDP en privé svp
[2014-08-28 21:13:29] <Nicofuma> Pour l'espace disque, si ce sont les images, ce qui serait intéressant à savoir c'est si c'est à cause du nombre d'images ou juste car il y trop d'images d'une qualité aberrante.
[2014-08-28 21:13:39] <SpaceFox> le principal pb vient des accès disques assez aléatoires en temps de réponse, sinon tout roule
[2014-08-28 21:13:52] <Nodraak1> -> faut reduire les images
[2014-08-28 21:14:01] <pierre_24> SpaceFox: Et y'a une raison à ça ?
[2014-08-28 21:14:11] <firm1> Nicofuma: je pense que depuis qu'on fait des import de tutos venant du SDZ on a des pic de chaleur
[2014-08-28 21:14:12] <SpaceFox> pierre_24> oui, on est sur un VPS pas cher
[2014-08-28 21:14:29] <SpaceFox> cela dit ils ont du nous bouger de serveur, parce qu'on a moins de pics de latence qu'à un moment
[2014-08-28 21:14:36] <SpaceFox> cf http://munin.kisai.info/zestedesavoir.com/www.zestedesavoir.com/zds_db_performance.html
[2014-08-28 21:14:41] <firm1> on a dejà une limite des images de la galleries a 1Mo par image
[2014-08-28 21:15:40] <SpaceFox> (10 PR en attente, coucou Eskimon !)
[2014-08-28 21:15:43] <firm1> En parlant d'optimsation, le cache, il faudra y penser
[2014-08-28 21:15:49] <pierre_24> Pour
[2014-08-28 21:15:54] <firm1> mais après la V1
[2014-08-28 21:15:56] <Nodraak1> cest grave cette histoire de disque ? au pire un rajoute un hd ? cest plus ca qui coute cher aujourdhui si ?
[2014-08-28 21:15:59] <Nicofuma> L'import de tuto fonctionne coment vis à vis des images ?
[2014-08-28 21:16:05] <SpaceFox> Nodraak1> on a pas du tout la main dessus, c'est un VPS
[2014-08-28 21:16:18] <SpaceFox> "pas la main" = "on a même pas les stats de latence, je vois ça grâce à la BDD"
[2014-08-28 21:16:43] <firm1> Nicofuma: quand on importe un tuto, on rajoute les images du tuto, les images sont téléchargées sur le serveur et c'est tous
[2014-08-28 21:16:56] <firm1> elles sont parfois dupliqués pour générer les pdf et tout
[2014-08-28 21:17:04] <firm1> bref, on sort du sujet
[2014-08-28 21:17:06] <firm1> :)
[2014-08-28 21:17:29] <Akulen> je pense qu'il voulait savoir si la taille etait verifiee
[2014-08-28 21:17:31] <firm1> ça vous dit, on passe au prochain points ? ou vous voulez faire une pause
[2014-08-28 21:17:40] <SpaceFox> Pour le cache, on a une issue dessus - mais c'est du gros boulot bien complexe
[2014-08-28 21:17:42] <Nicofuma> Akulen: je pensais à ça oui
[2014-08-28 21:17:47] <firm1> Akulen: j'ai pas ma console ssh là
[2014-08-28 21:17:51] <SpaceFox> personnellement j'aimerais finir une bonne fois pour toutes
[2014-08-28 21:18:05] <firm1> SpaceFox: tu pourrais nous sortir les chiffres de /opt/zdsenv/ZestedeSavoir/media ?
[2014-08-28 21:18:10] <Nicofuma> je sais plus si le sdz mettait une limite de taille et si oui laquelle. Mais je pense qu'il y en avait une
[2014-08-28 21:18:48] <firm1> Nicofuma: on a une limite de Mo sur les images de ZDS
[2014-08-28 21:18:52] <SpaceFox> root@zds-prod:/opt/zdsenv/ZesteDeSavoir/media# du -sh *
[2014-08-28 21:18:52] <SpaceFox> 1,1M articles
[2014-08-28 21:18:52] <SpaceFox> 4,0K categorie
[2014-08-28 21:18:52] <SpaceFox> 4,0K forum
[2014-08-28 21:18:52] <SpaceFox> 1,4G galleries
[2014-08-28 21:18:52] <SpaceFox> 39M pygal
[2014-08-28 21:18:53] <firm1> Bon allez on avance
[2014-08-28 21:19:04] <firm1> Ah lec hiffres
[2014-08-28 21:19:33] <Nicofuma> Donc c'est juste un problème de nombre d'images et donc de scabilité, rien de bien surprenant ni génant (c'était prévisible quoi) :)
[2014-08-28 21:19:42] <firm1> Nicofuma: oui
[2014-08-28 21:19:50] <firm1> Allez ! NEXT POINT
[2014-08-28 21:19:56] <firm1> Les MEPs
[2014-08-28 21:20:11] <pierre_24> Y'a le zestflow qui défini ça, nan ?
[2014-08-28 21:20:21] <firm1> L'idée est (a partir de la v1) d'avoir des cycles
[2014-08-28 21:20:21] <Eskimon> pas la frequence et compagnie
[2014-08-28 21:20:26] <Eskimon> voila
[2014-08-28 21:20:28] <firm1> genre des MEP toutes les xxx
[2014-08-28 21:20:48] <firm1> et une séance de QA collectives sur la preprod avant
[2014-08-28 21:20:57] <SpaceFox> firm1> L'idée est (a partir de la v1) d'avoir des cycles
[2014-08-28 21:21:02] <firm1> ça permet a la comm de préparer des truc sur les nouveautés
[2014-08-28 21:21:04] <SpaceFox> alors déjà pour moi on est pas d'accord
[2014-08-28 21:21:08] <Eskimon> Avec GA il y a moyen de savoir le moment de la semaine ou il y a le moins de frequentations ?
[2014-08-28 21:21:22] <SpaceFox> pour moi, l'idée est d'avoir des MEP dès qu'on en a une de prête
[2014-08-28 21:21:27] <Nodraak1> easy, deja pas le we, je dirait le mardi
[2014-08-28 21:21:29] <SpaceFox> Eskimon> clairement le WE
[2014-08-28 21:21:48] <Nodraak1> spacefox : le moins de frequentation ?
[2014-08-28 21:21:50] <SpaceFox> Perdu Nodraak1, tu peux vérifier les stats Nginx sur le lien que j'ai filé plus tôt
[2014-08-28 21:21:55] <SpaceFox> le dimanche est de loin le moins fréquenté
[2014-08-28 21:22:13] <firm1> N'oublions pas qu'on sort de vacances là
[2014-08-28 21:22:14] <Nicofuma> Les stats sont faussés en ce moment
[2014-08-28 21:22:16] <Eskimon> (tiens comme sur mon blog :D )
[2014-08-28 21:22:16] <Nicofuma> on est fin aout
[2014-08-28 21:22:26] <Nicofuma> la semaine prochaien c'est la rentrée
[2014-08-28 21:22:31] <firm1> voila
[2014-08-28 21:22:34] <SpaceFox> m'enfin, tout ça pour dire que c'est super facile à vérifier et à s'adapter
[2014-08-28 21:22:59] <firm1> bref, donc on note qu'il faut MEP a des horaires de faibles audiences
[2014-08-28 21:23:01] <Eskimon> De toute facon je pense qu'il faut aussi etre realiste, le dimanche c'est aussi le jour on a tous plus le temps pour pas se mettre la pression sur une MEP… Si un truc merde on peut y aller tranquillou
[2014-08-28 21:23:27] <SpaceFox> Pour en revenir aux cycles de MEP : pour moi il ne faut PAS planifier des dates, parce que ça nous met des deadlines et donc une pression
[2014-08-28 21:23:49] <firm1> SpaceFox: ok pour ne pas plannifier
[2014-08-28 21:23:52] <pierre_24> +1 pour SpaceFox … Y'à qu'a voir les milestone qu'on rempli jamais
[2014-08-28 21:23:54] <SpaceFox> de mon point de vue, il vaut mieux se dire "OK, là on a assez de nouveautés / un gros truc en attente, on lance une release"
[2014-08-28 21:24:03] <Nodraak1> +1
[2014-08-28 21:24:23] <SpaceFox> et là on peut préparer une comm (sans la publier) parce qu'on sait que 2 semaines plus tard, soit on a MEP, soit on a abandonné la release
[2014-08-28 21:24:23] <firm1> mais ce que je voulais surtout dire c'est, une release qui dure plus de 4 semaines c'est long
[2014-08-28 21:24:43] <Eskimon> surtout qu'on va tendre vers une rythme de plus en plus faible ( moins en moins de bug à corriger et des features probablement de plus en plus longues a dev)
[2014-08-28 21:24:53] <SpaceFox> ah oui, je suis d'accord, dans ce que je propose au bout de 2 semaines on abandonne la release, surtout si on a autre chose qu'une typo à corriger
[2014-08-28 21:25:00] <Eskimon> arf ca colle pas avec firm1 mon "surtout"
[2014-08-28 21:25:25] <Eskimon> bref, pas de révision = safe
[2014-08-28 21:25:29] <Eskimon> +p
[2014-08-28 21:25:53] <SpaceFox> cf ici pour les détails : https://github.com/zestedesavoir/zds-site/pull/1395/files#diff-8c7671aad8ade3c2021331870aa39775R53
[2014-08-28 21:26:11] <firm1> donc si je résume on se dit, une release ne doit pas aller au dela de deux semaine ? si on doit en arriver là on merge la release et on repart ?
[2014-08-28 21:26:23] <SpaceFox> voilà
[2014-08-28 21:26:38] <firm1> moi ça me va
[2014-08-28 21:26:38] <SpaceFox> c'était mon idée, si quelqu'un voit que ça va foirer, c'est le moment
[2014-08-28 21:26:49] <firm1> au pire j'ai une guinness
[2014-08-28 21:26:55] <pierre_24> Je vois pas pourquoi ça foirerai ^^
[2014-08-28 21:27:29] <firm1> Bon Next POINT alors. (J'adore ce meeting, on est vachement productif)
[2014-08-28 21:27:41] <firm1> L'automatisation de la MEP
[2014-08-28 21:27:51] <firm1> y'a encore des choses a faire sur le script de MEP ?
[2014-08-28 21:28:23] <SpaceFox> Pour moi, il est OK
[2014-08-28 21:28:32] <SpaceFox> (enfin avec le code actuel)
[2014-08-28 21:28:39] <pierre_24> firm1: t'as dis toi même qu'il était sympa :p
[2014-08-28 21:28:53] <firm1> oui mais je n'ai pas tester les cas de migrations
[2014-08-28 21:28:55] <firm1> :)
[2014-08-28 21:29:03] <firm1> mais s'il est ok, c'est cool
[2014-08-28 21:29:16] <firm1> c'est surtout pour qu'on soit tous synchri
[2014-08-28 21:29:24] <firm1> Next
[2014-08-28 21:29:34] <firm1> Le Monitoring, ça a l'air de rouler aussi
[2014-08-28 21:29:45] <pierre_24> Le quoi ?
[2014-08-28 21:29:53] <firm1> Sentry et Munin
[2014-08-28 21:30:02] <firm1> Vous avez tous vos accès ?
[2014-08-28 21:30:07] <pierre_24> Non ;)
[2014-08-28 21:30:11] <firm1> Si c'est pas le cas, il faut demander a Sapcefox
[2014-08-28 21:30:14] <SpaceFox> J'ai toujours pas réussi à monitorer Solr mais sinon c'est bon
[2014-08-28 21:30:24] <pierre_24> mais spacefox a dit plus haut qu'il préferai pas donner l'accès à tout le monde
[2014-08-28 21:30:29] <SpaceFox> Munin vous l'avez dans cette conversation
[2014-08-28 21:30:36] <SpaceFox> Sentry je vous le donnerai si vous en avez besoinpour un bug
[2014-08-28 21:30:44] <artragis> non, j'y a plus pensé à l'époque
[2014-08-28 21:30:47] <SpaceFox> vu que Sentry donne l'IP du membre, son mail, etc.
[2014-08-28 21:30:53] <firm1> SpaceFox: je pense qu'il faut (pour les reguier) donner l'accès
[2014-08-28 21:31:12] <SpaceFox> Ben à 2-3 personnes qui connaissent BIEN le code oui
[2014-08-28 21:31:17] <firm1> Ouaip
[2014-08-28 21:31:19] <SpaceFox> mais je peux clairement pas le filer à qui veut
[2014-08-28 21:31:25] <firm1> ça marche
[2014-08-28 21:31:36] <firm1> Bon, on en arrive au plus gros points
[2014-08-28 21:31:42] <firm1> les ZEPs
[2014-08-28 21:31:59] <firm1> Petit resumé, les ZEP sont des sortes de cahiers de charges des devs
[2014-08-28 21:32:07] <firm1> qui décrivent de manière fonctionnel un besoin
[2014-08-28 21:32:18] <firm1> On en a 15 je crois
[2014-08-28 21:32:21] <firm1> actuellement
[2014-08-28 21:32:34] <artragis> la plus avancée actuellement est la 12
[2014-08-28 21:32:41] <firm1> Je voulais surtout svoir si certains sont attirés/ont commencé une ZEP
[2014-08-28 21:33:00] <pierre_24> J'ai déjà répondu à cette question, perso :p
[2014-08-28 21:33:12] <Akulen> la 10 me plait, mais elle a l'air freeze pour le moment (vacances ?)
[2014-08-28 21:33:13] <artragis> je m'occupe de la rédaction de la 8 et je serai très actif sur cette zep là en plus de la 12 avec pierre_24
[2014-08-28 21:33:14] <pierre_24> (et faut que je lise sérieusement la 15, ça a l'air cool)
[2014-08-28 21:33:48] <Florian> Moi perso j'ai rédigé une ZEP sur l'éditeur du site (mais c'est plutôt de l'ordre du front et de Alex-D). GuilOOo voulait aussi faire une ZEP pour le réglement sur les forums, si je me souviens bien
[2014-08-28 21:34:01] <firm1> Je crois que la 02 est prise par Andr0
[2014-08-28 21:34:06] <Eskimon> C'est quoi la 8, 10, 12 ?
[2014-08-28 21:34:18] <SpaceFox> Eskimon> http://zestedesavoir.com/forums/sujets/tag/51/zep/
[2014-08-28 21:34:28] <Eskimon> merci SpaceFox
[2014-08-28 21:34:34] <artragis> 8 -> git ^1000 12 -> refactorisation des modules de tuto et article
[2014-08-28 21:34:53] <firm1> Pour la ZEP 05 (markdown) Kje je disais qu'on manque d'effectif
[2014-08-28 21:35:04] <firm1> j'ai lu rapidement le code de pandoc il y'a quelques jours
[2014-08-28 21:35:12] <Eskimon> Perso je serais pour me garder la 3 (page resumant les tutos en cours d'ecriture) et la 7 (ajout de champ dans le profil)
[2014-08-28 21:35:19] <firm1> au final c'est assez trivial de rajouter des entrée dans pandoc
[2014-08-28 21:36:14] <firm1> Donc les ZEP réservée sont : 2, 3, 7, 8, 10, 12
[2014-08-28 21:36:39] <Alex-D> la 4 est à faire pour ce qui concerne le back
[2014-08-28 21:36:48] <Eskimon> Sandhose, tu étais pas chaud pour les stats dans la 11 ?
[2014-08-28 21:37:01] <Alex-D> Eskimon, il faut le back pour faire le front ^^
[2014-08-28 21:37:10] <pierre_24> Alex-D: c'est quoi, encore la 4 ?
[2014-08-28 21:37:12] <SpaceFox> La 11 est à voir avec Shigerum je crois
[2014-08-28 21:37:33] <Eskimon> Ouai je te l'accorde, mais il avait l'air motivé et il y a pas mal de front, du coup en s'associant avec un dev back…
[2014-08-28 21:37:43] <Alex-D> pierre_24, c'est l'accueil si je me goure pas
[2014-08-28 21:37:47] <firm1> Bon, maintenant ce qu'il est important c'est de classer les ZEP par priorité !
[2014-08-28 21:37:49] <Alex-D> pierre_24, http://zestedesavoir.com/forums/sujet/669/zep-04-nouvelle-page-daccueil/
[2014-08-28 21:37:53] <Sandhose> Eskimon: Il me faudrait pas mal de back pour celle la
[2014-08-28 21:38:22] <Sandhose> Eskimon: J'ai déjà joué avec les APIs Google, je peux aider à ce niveau la, mais le python par contre…
[2014-08-28 21:38:22] <Alex-D> Eskimon, c'est quedal le front des stats
[2014-08-28 21:38:27] <SpaceFox> Il faudrait que je relise la 4 mais il me semble qu'il y manque un truc ultra important
[2014-08-28 21:38:34] <Alex-D> suffit de balancer des graphs
[2014-08-28 21:38:43] <SpaceFox> un article et/ou un tuto au hasard
[2014-08-28 21:38:45] <firm1> On avait dit qu'on restait sur une reunion back
[2014-08-28 21:38:49] <Sandhose> Ouais, niveau front, c'est une lib pour des graphs (D3.js <3 ) et basta
[2014-08-28 21:39:12] <SpaceFox> Bon, plus rien à dire sur les ZEP ?
[2014-08-28 21:39:13] <firm1> :(
[2014-08-28 21:39:13] <Alex-D> yep firm1 mais ce qu'on dit c'est qu'il faut avancer le back pour les ZEP qui semblent être du front :)
[2014-08-28 21:39:19] <Sandhose> firm1: On est justement en train de dire que cette ZEP, nous on a pas beaucoup de choses à faire
[2014-08-28 21:39:38] <Alex-D> SpaceFox, pour la 4 (accueil) il faut les sujets chauds
[2014-08-28 21:39:50] <pierre_24> Alex-D: juste, y'à ça
[2014-08-28 21:39:52] <firm1> Revenons sur les zep prioritaires
[2014-08-28 21:40:04] <SpaceFox> Alex-D> j'en reparlerai sur la ZEP
[2014-08-28 21:40:13] <Alex-D> okdac SpaceFox
[2014-08-28 21:40:35] <Alex-D> firm1, prioritaire selon moi : toutes les ZEP autour de la refacto des tutos, donc les 8 et 12 de tête
[2014-08-28 21:40:41] <Alex-D> ainsi que l'API (la 2)
[2014-08-28 21:40:44] <firm1> Si vous devez donner 2 ZEP a réaliser pour vous ça serait quoi ?
[2014-08-28 21:40:46] <Eskimon> +1 avec Alex-D
[2014-08-28 21:40:52] <pierre_24> +1 pour l'api
[2014-08-28 21:41:04] <firm1> En sachant qu'on peut pas tout faire d'un coup
[2014-08-28 21:41:07] <Alex-D> la 8 et la 12 bien que différentes sont ultra liées
[2014-08-28 21:41:17] <pierre_24> Oui
[2014-08-28 21:41:22] <SpaceFox> pour moi la 4 (accueil), puis la 8 et la 12 ensemble
[2014-08-28 21:41:36] <SpaceFox> à moins que la 4 dépende des 2 autres
[2014-08-28 21:42:03] <Alex-D> le problème de la 4 c'est qu'elle est pas fixée et que personne ne dit si oui ou non ça plait et autres idées d'amélioration
[2014-08-28 21:42:19] <firm1> Personne ne parle de la tribune libre ZEP 13 (plutot simple a implémenter par rapport aux mastodonte) ?
[2014-08-28 21:42:25] <SpaceFox> Ah ça c'est le même problème pour toutes les ZEP : il faut les faire vivre
[2014-08-28 21:42:35] <Alex-D> donc soit on considère qu'elle est bonne à coder et du coup, en effet elle devient prioritaire
[2014-08-28 21:42:41] <pierre_24> De manière générale, le concept des ZEP est génial, mais des zep stagne pendant des semaines, parce que personne dit rien
[2014-08-28 21:42:43] <SpaceFox> la 13 pour moi devrait attendre la 8 et la 12 pour éviter des problèmes de refactoring sales après
[2014-08-28 21:43:10] <Eskimon> (n'oubliez pas que c'était les vacances pour beaucoup de monde)
[2014-08-28 21:43:17] <Alex-D> SpaceFox, au contraire, il faut que la 8 et la 12 soient faites de façon à ce que la 13 soit faisable facilement
[2014-08-28 21:43:25] <Alex-D> ça prouverait la souplesse du bouzin
[2014-08-28 21:43:30] <SpaceFox> Alex-D> on dit exactement la même chose
[2014-08-28 21:43:33] <firm1> lol
[2014-08-28 21:43:40] <Alex-D> ah merde j'ai mal lu, désolé SpaceFox
[2014-08-28 21:43:42] <Eskimon> XD
[2014-08-28 21:44:02] <firm1> en effet, ce qui ressort donc a chaque fois ce sont les zep 4, 8 et 12
[2014-08-28 21:44:09] <SpaceFox> 100% d'accord
[2014-08-28 21:44:11] <Alex-D> sachant que 8 et 12 = pur back
[2014-08-28 21:44:18] <firm1> ça vous dit, qu'on donne TOUT pour ces deux ZEP ?
[2014-08-28 21:44:21] <firm1> 3 ZEP
[2014-08-28 21:44:21] <pierre_24> Oh yeah <3
[2014-08-28 21:44:27] <SpaceFox> \o/
[2014-08-28 21:44:28] <artragis> … pour ce qui est des PR et tout il faut du front
[2014-08-28 21:44:34] <artragis> notamment pour l'intégration mobile !
[2014-08-28 21:44:49] <artragis> Et surtout pour mieux intégrer le fichier diff
[2014-08-28 21:44:52] <firm1> Avec une pointe de priorité majeure du back pour la 4 pour donner du grain a moudre coté front
[2014-08-28 21:45:05] <pierre_24> +1 firm1
[2014-08-28 21:45:07] <Alex-D> et que la 4 va nécessiter du back (un peu d'algo) il faut aussi du cache car du coup ça va amener des requêtes costaud
[2014-08-28 21:45:16] <Alex-D> côté front y a de toute façon encore de quoi faire
[2014-08-28 21:45:28] <Alex-D> artragis, je ne comprends pas ce que tu veux dire
[2014-08-28 21:45:30] <artragis> Pour ce qui est de 8 et de 12 il y a encore des efforts de rédaction à faire
[2014-08-28 21:45:50] <pierre_24> artragis: de fait
[2014-08-28 21:45:52] <artragis> Alex-D : le diff tel qu'il est actuellement n'est absolument pas lisible : il prend plus que l'écran
[2014-08-28 21:45:52] <SpaceFox> +1 firm1, +1 artragis et on est pas là pour résoudre les pb techniques des ZEP
[2014-08-28 21:45:54] <firm1> artragis: c'est bien ce que je dis en disant "On donne tout pour ces 3 ZEP"
[2014-08-28 21:46:02] <SpaceFox> OK, donc la suite ?
[2014-08-28 21:46:02] <Alex-D> artragis, ah oui, mais là on s'en fou on parle du back
[2014-08-28 21:46:15] <Alex-D> et des parties du front importantes qui sont bloquées par le back (genre l'accueil)
[2014-08-28 21:46:35] <firm1> ça m'a l'air bon.
[2014-08-28 21:46:42] <SpaceFox> firm1> il reste des trucs dans l'ordre du jour ? Sinon j'en rajoute un qui prends 2 minutes
[2014-08-28 21:46:42] <pierre_24> Alex-D: faut se mettre d'accord sur l'algo de la zep4
[2014-08-28 21:46:49] <SpaceFox> pierre_24> c'est pas le sujet
[2014-08-28 21:46:53] <Alex-D> pierre_24, bah faut en discuter dans la ZEP 4 ^^
[2014-08-28 21:46:57] <pierre_24> de fait ^^
[2014-08-28 21:46:58] <SpaceFox> voilà
[2014-08-28 21:47:03] <firm1> SpaceFox: on a fini là
[2014-08-28 21:47:09] <SpaceFox> OK, j'ai juste une demande
[2014-08-28 21:47:13] <SpaceFox> donnez votre avis ici http://zestedesavoir.com/forums/sujet/954/creer-un-depot-github-pour-gerer-les-issues-infra/
[2014-08-28 21:47:29] <SpaceFox> Je poste les logs sur le site
[2014-08-28 21:47:33] <SpaceFox> Merci à tous et bonne soirée !

Edit : correction du Markdown des logs

Édité par SpaceFox

Staff

Merci pour ces logs.

[2014-08-28 21:37:12] <SpaceFox> La 11 est à voir avec Shigerum je crois

J'ai en effet quelques idées qu'il faudrait que je pose sur le papier pour vous les soumettre. Je ferai ça dans la ZEP 11 directement, même si ça va au-delà de cette ZEP car ça ne concernerait pas que les stats des tutos. Mais j'ai peu de temps en ce moment donc ne m'attendez pas si vous voulez partir sur d'autres solutions.

Suivez ZdS sur Twitter ! Et venez aux JZDS Lille !

+0 -0

Bon j'ai tout lu, très intéressant mais brut comme ça c'est pas vraiment digeste. firm1 a bien découpé l'ordre du jour en différents sujets, ça serait possible de mettre des titres dans le log ? Ou c'est trop pénible / bordélique ? (typiquement je serais allé directement lire le passage sur les ZEP).

D'ailleurs à ce sujet j'ai finalement pas vu de conclusion, firm1 demande les deux plus prioritaires mais je vois pas vraiment de conclusion. La ZEP 02 m'intéresse mais on n'est pas énormément à donner notre avis dessus, je sais pas trop si ça signifie qu'il y a consensus ou que les gens sont pas intéressés ou pas vraiment d'accord sur la marche à suivre, ou pire : ne comprennent pas de quoi on parle.

Du coup pour les ZEP, quelqu'un avait évoqué un sujet/tableau de suivi et on avait répondu "il suffit de filtrer sur le tag ZEP" certes, mais pour fixer les priorités et se cantonner à "il faut de l'aide là-bas", "on veut passer ça en premier" et conserver les discussions fonctionnelles ou techniques dans les sujets des ZEP c'est ptêtre pas une mauvaise idée au final non ? Ou alors se servir du sujet de nohar sur la roadmap, mais c'est vrai qu'on a 15 ZEP en cours et que perso je m'y perds un peu.

J'aimerais aider autant que faire se peut (quitte à mettre les mains dedans, même si je reconnais avoir du mal -et presque un peu peur- à me mettre à Django+Zestflow) notamment sur la ZEP 02, mais je suis pas certain d'où on en est, de comment on veut s'organiser et d'où on veut aller :\

Édité par Javier

Happiness is a warm puppy

+0 -0

Je me tente a l'exercice du résumé, de ce que j'ai vecu hier soir dans le chat (sans relire le log, corriger moi si je me trompe) (pardonnez moi les accents, qwerty et pas le courage de corriger tout)

  • La chaine de développement
    • La doc : ses manques, ses zones d'ombres, les dépendances du projet
      • La doc doit être complétée ! Point de vue technique ca peut nécessite des ajustements dans le code, mais point de vue fonctionnel il y a un gros vide. Elle doit être encouragée durant la phase de QA si elle n'est pas encore faite. (je n'ai pas de souvenir sur le support a utiliser, soit dans le code ou dans le wiki GH ou sur le forum ?). Les docs d'installation et de contributing sont en revanche bien avancée/finalisée.
    • Le workflow : ZestFlow, QA, Intégration Continue
      • Le workflow est une adaptation du gitflow que l'on nomme zestflow :soleil: . En simple : Tout développement se fait sur la branche dev et passe par des PR et QA pour être intégré. Une fois de temps en temps (voire plus bas), la branche dev est dupliquée dans une branche de release. Cette dernière est alors éprouvée sur la preprod qui est sous-utilisée en ce moment. Cette branche de release ne reçoit alors que des bugfix puis est ensuite merge dans prod lors d'une Mise En Production (MEP) (cf plus bas).
    • Les modules sensibles : tutoriels, etc.
      • Long story short : go ZEP 8 et 12 pour plus d'infos a ce sujet
    • Le qualité du code : lisibilité (PEP8), refactoring, bonnes pratiques
      • PEP8 doit etre encouragee et meme indispensable a partir d'un moment. Le code ne devra plus etre fusionne dans le code commun si les règles PEP ne sont pas respectée. Pour cela, il serait bon d'avoir un hook de pre-commit git pour éviter des commits "fix pep" polluant. Travis devra échouer si PEP non respecte. Il faudra trouver le meilleur timing possible pour rePEPiser tout le code (lorsque les PR en attente seront passée ?)
      • Une refacto serait a prevoir. Elle est dual. D'une part, pour limiter de nombreuses redondances de code un peu partout. D'autres part, pour éclater certains gros fichiers (surtout les views.py) en plus petit fichiers.
    • Les goulots d’étranglements et optimisations : profiling, …
      • Apparemment les choses ne sont pas si mal. Certains tables de la BDD ne possede pas d'index ce qui plombe les perfs. Il faudra investiguer pour résoudre cela mais des outils existent et sont en place pour résoudre cela.
      • Sans grande surprise, les images prennent le plus de place sur le disques durs.
  • Les MEPS
    • Le cycle de vie
      • Comme dit plus haut, le zestflow sera applique. Lors d'une mise en production, l'equipe comm' fera surement une news pour parler des nouveautés.
    • Des dates régulières ?
      • Non. Il a été acte qu'il ne sert a rien de se mettre la pression en s'imposant des dates. Si un contenu suffisant est prêt pour faire une release alors ce sera fait. Cependant, afin d’éviter d'attendre pour introduire de nouvelles choses qui fonctionne, un timeout sera fait pour mettre en prod (autrement dit, on attend un minimum de choses pour faire une release, mais si ce minimum n'est pas atteint on se force pas et release quand même ce qui est présent).
      • Le dimanche a l'air d’être un jour de préférence pour faire les mise en prod, notamment car c'est le jour de moindre fréquentation (pour le moment, nous étions en vacances scolaires cependant).
    • Automatisation
      • Le script semble marcher correctement. Rien a ajouter a ce sujet.
    • Monitoring : sentry, munin, …
      • Divers outils sont en oeuvre. Les accès sont a demander a SpaceFox car des données prives aux membres peuvent être visible (IP, email etc).
  • Les ZEPs
    • État des lieux et suivi
      • Faire vivre une ZEP n'est pas un exercice simple. Il semblerait qu'il arrive tres souvent qu'elle arrive dans un etat de pause qu'il faut alors reussir a relancer pour rechercher des consensus et lever les verrous.
    • Priorités
      • La priorité est donnée aux ZEP 4 - 8 - 12 (page d'accueil (4) et refonte des tutos (8-12)).
    • Qui veut s'occuper de quoi ?
      • Je ne me rappel plus, lire le log SVP !

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+7 -0
Staff
Auteur du sujet

On a parlé de refaire un meeting 1 mois après le précédent, donc je pense qu'on peut déjà trouver une date. Cette fois ci, on pourra resserrer un peu l'ordre du jour pour que ça dure 1 heure grand max.

Je propose d'aborder les points suivants :

  1. REX des actions du meeting #1
  2. Les difficultés rencontrées dans la V1.1
  3. Le ZestFlow et les ZEPs

J'ai le sentiment d'oublier des trucs, mais je pense créer un doodle dans la soirée pour voir la date.

Ca ira peut-etre dans ton point 1. ou 2. , mais j'aimerais bien qu'on parle de la QA. Actuellement il y a un gros souci d’efficacité/effectif, et c'est un peu toujours les mêmes qui s'y colle… Du coup on a une pile de PR qui s'entasse sans possibilité de trop avancer… (la v1.1 aurait pu voir le jour depuis un moment sinon)

Édité par Eskimon

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+2 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte