Préparation du déploiement de la v1.3

Quand et avec quoi ?

a marqué ce sujet comme résolu.

Édit du 22/11 :

La version 1.3 a été déployée en pré-production à l'adresse suivante : http://preprod.zestedesavoir.com
Identifiants : clementine / souris

Les points à tester sont listés sur Github, ce qui n'empêche pas de tester plus largement que la v.1.3 n'a pas apporté de régressions.

Le topic de retours sur la v1.3 est ici : http://preprod.zestedesavoir.com/forums/communaute/v1_3/


Hello,

ça fait un moment que les PRs sont mergées les issues derrières les autres, et on peut se demander si le moment est venu de lancer la v1.3. Étant donné qu'on a pas de visibilité assez fine depuis Github, en attendant de trouver une solution pérenne, je vais me servir de ce Topic pour faire l'inventaire des issues actuellement dans la stack de la v1.3.

Ce sujet nous servira aussi pour savoir quand lancer la release en préproduction pour avoir un maximum de testeurs disponibles.

Je mettrais à jour le Topic au fur et à mesure de l'arrivée d'une issue.

Les fonctionnalités

Majeures

issue description
1133 Il est possible désormais de rajouter un message de révision pour chacune de nos modifications de tutoriel/article. Un message par défaut est renseigné si on ne mets rien.
1621 et 523 L'interface (bouton, menu, messages, etc.) du site est maintenant internationalisée. Ce qui signifie qu'on peut maintenant utilisé le code du site pour monter un site dans une autre langue. Ce qui permet aussi de contrôler les chaines de caractères dans un seul et même fichier
1720 Les staffs peuvent maintenant rajouter un karma (et un message associé) à un membre.

Mineures

issue description
1135 Lorsque la validation refusait (ou acceptait) un tuto (article ?) un MP de justification était envoyé a chaque auteur. Maintenant, un MP global avec tout les auteurs est envoyé
1153 Les boutons de mise en forme (gras, italique, etc.) sont maintenant bloqué lorsqu'on soumet un formulaire.
1626 L'accessibilité de la liste des topics est légèrement améliorée. On a des balises <h4> pour les titres des topics.
1729 Un nouveau filtre « Sujets sans réponse » fait son apparition dans les forums
1632 La liste des noms de domaines interdit à l'inscription a été mis à jour. On a par exemple : @ano-mail.net, @buffemail.com, etc.
766 Améliorer le rendu des diffs sur les tutoriels. Actuellement il est inexploitable.
1701 Pour les staffs il est maintenant possible de voir sur la page de profil d'un membre leur activité sur les forums.

potentiellement dans la v1.3 (en cours de PR)

issue description
1744 Sur l'interface de création d'un article/tutoriel on affiche un lien qui explique toutes les licences.
1731 Permettre de trier ses articles et tutoriels par ordre alphabétique.
1334 Rend possible la validation partielle d'un tutoriel. C'est à dire qu'on envoi en validation uniquement les extrait qu'on veut.
531 Une page qui résume l'ensemble des tutoriel qui ont besoin d'aide. Plus d'informations dans la ZEP-03

Les corrections de bugs

Bloquantes

issue description
1544 Les tutoriels renommés après dépublications ne plantent plus à la prochaine publication.

Non bloquantes

issue description
1608 Avant, quand on dé-publiait un tutoriel, et qu'on avais encore des notifications sur ses commentaires, on gardait une notification inaccessible, car le tutoriel était hors ligne.
1546 Les liens dans les flux RSS des tutoriels et articles pointent maintenant sur la version en ligne plutot que celle hors-ligne comme c'était le cas avant.
1557 Le bouton "Afficher l'aide Markdown" se ne se superpose plus au bouton "Aperçu" sur mobile
1606 Les pouces ne sont plus décalés sur mobile
1618 L'heure de l'alerte affichée dans la boite de notifications des staffs est maintenant celle de l’alerte plutôt que celle du message posté comme avant.
1631 Le message d'avertissement de suppression d'une gallérie n'était pas bien formaté et faisait planter le serveur.
1633 Les messages d'erreurs sont maintenant cohérents entre eux à la virgule près.
1644 L’icône des tutoriels ne chevauche plus le texte, comme c'était le cas sur cette image
1650 L’icône du site sur la page A propos ne rend plus aussi mal que ce qu'on voit sur cette image
1680 Maintenant lorsqu'on copie/colle le lien donné dans le détails d'une image dans un message de topic, on a bien la miniature et la version agrandi si on clique dessus. Avant il fallait rajouter l'url zestedesavoir.com devant.
1682 Avant, on avait une erreur 500 au lieu d'une erreur 404 si on allait sur une page inexistante des commentaires d'un article.
1756 On a plus de bouton pour s'envoyer un MP à soi même dans son profil.
1643 La sidebar de la zone de profil devient logique, car elle considère maintenant qu'un article publié n'est plus un article est brouillon.
1694 On n'affiche plus le lien de téléchargement de l'archive d'un tutoriel alors qu'on est sur l'interface de création.
1776 Les liens de source de citations manquaient d'url dans les commentaires de tutoriels. C'est maintenant corrigé.

potentiellement dans la v1.3 (en cours de PR)

issue description
1560 L'affichage des licences est maintenant le même partout sur les tutoriels et articles.

Il faut donc savoir si on lance une release avec la stack actuelle, ou on attend de faire passer les PRs a venir ? Si jamais on lance un release d'ici la fin de la semaine, vous serez dispo pour tester en masse sur la préprod ?

A venir (en cours de PR)

Alors, je vais faire mon lourd, mais il n'y a pas de "à venir (en cours de PR)" dans une release. Une PR ne peut être incluse dans une release que lorsqu'elle est mergée, pas avant. Cf le zestflow pour les détails.

Donc, tu peux soit benner tous les tableaux "A venir", soit les renommer en "potentiellement dans la v1.3 si elles sont mergées le jour où on lance la release".

Sachant que ce jour risque fort d'être ce soir, vue la quantité d'issues qu'on a déjà mergées.

PS : du coup la visibilité Github est d'une finesse parfaite, puisqu'il suffit de filtrer sur la milestone v1.3 pour avoir le contenu exact de la v1.3 (en admettant que cette milestone a correctement été MAJ lors des merges).

+1 Spacefox et même si j'aurais aimé que la 1.3 soit la release de notre premiere zep, je pense que ce qui est mergé est assez important pour ne plus trop attendre. Je vote donc pour "on lance la préprod dès qu'elle peut être installé".

+1 Spacefox et même si j'aurais aimé que la 1.3 soit la release de notre premiere zep, je pense que ce qui est mergé est assez important pour ne plus trop attendre. Je vote donc pour "on lance la préprod dès qu'elle peut être installé".

Kje

Rien ne m'aurait aussi fait plus plaisir, mais rien ne sert de courir…

Ne nous retrouvons pas dans le cas de la deinscription, je pense comme toi et plein de mondes que ASAP est le bon plan, quitte a faire une autre release plus legere plus tard

+0 -0

Alors, je vais faire mon lourd, mais il n'y a pas de "à venir (en cours de PR)" dans une release

Oui, je sais. Mais l'idée c'est surtout de présenter ce qui pourrait potentiellement rentrer dans la PR dans les prochains jours et de décider si oui ou non on l'attend pour lancer la PR. Donc le titre est à renommer en effet.

PS : du coup la visibilité Github est d'une finesse parfaite,

SpaceFox

Bah, non parce que pour trouver les PRs proches de la sortie je me suis tapé toutes les PRs inutiles (WIP, etc.) avant :)

Le but initial du topic reste la préparation de la V1.3. D'ou les questions sur la fin :

  • y'aura des testeurs de dispo ? Pour éviter ce qui s'est passé pendant la release de la 1.2, ou on a lancé une release comme ça et on la fermé après 2 semaines alors qu'on ne l'a pas testé.
  • ça vaut le coup d'attendre 1 ou 2 PRs (genre l'issue #1560 qui devrait être bonne) pour lancer la release ? ou il faut la repousser à la prochaine ?

L'idée c'est donc d'éviter les release surprise quoi :D

Bon, petit point sur les "A venir" :

[…] alors qu'on ne l'a pas testé.

Perso j'avais ete teste un petit peu :ange:

On organise un concours du meilleur chasseur de bug sur un weekend ? Le membre qui trouve le plus de bug sera érigé en héros dans l'article de présentation de la V1.3 (et on fait ca a chaque release) ?

+0 -0

Bah, non parce que pour trouver les PRs proches de la sortie je me suis tapé toutes les PRs inutiles (WIP, etc.) avant :)

Ce sont les tickets qui sont dans la version et non les PR (exception pour les PR tellement bidon qu'elles n'ont pas de ticket, genre une correction typographique). Mais "trouver les PR proches de la sortie" n'est pas vraiment un besoin, à mon sens. Notre workflow fait qu'on se fiche de savoir ce qui est "proche" de la sortie, uniquement de ce qui est prêt à être sorti.

On organise un concours du meilleur chasseur de bug sur un weekend ? Le membre qui trouve le plus de bug sera érigé en héros dans l'article de présentation de la V1.3 (et on fait ca a chaque release) ?

On peut au moins le tenter une fois et voir l'impact !

On peut au moins le tenter une fois et voir l'impact !

Surtout que ca peut etre simple a faire… Si on peut avoir un fofo "Bugs 1.3" sur la preprod lors de la release, on a un endroit ou rassembler tout les rapports de bugs, les gérer et "compter les points" facilement. On aura un peu un "bounty challenge" a la google/facebook et consort mais en plus modeste et bonne franquette :D

+0 -0

Bah, non parce que pour trouver les PRs proches de la sortie je me suis tapé toutes les PRs inutiles (WIP, etc.) avant :)

Ce sont les tickets qui sont dans la version et non les PR (exception pour les PR tellement bidon qu'elles n'ont pas de ticket, genre une correction typographique). Mais "trouver les PR proches de la sortie" n'est pas vraiment un besoin, à mon sens. Notre workflow fait qu'on se fiche de savoir ce qui est "proche" de la sortie, uniquement de ce qui est prêt à être sorti.

SpaceFox

Hmmm, j'en parle déjà dans le topic lié a l'utilisation de github. Dans un cas comme celui-ci il faut faire le tri. Par exemple dans ma liste j'ai viré tout ce qui est issue lié a node.js, correction sur la doc ou tâches infra, car sa rajouterais du bruit. Et pour ça il faut relire chaque issue.

Parfois on a des PRs qui corrigent une partie d'une issue. Idem a filtrer.

En résumé non, github ne permet pas facilement d'avoir une vue "testeurs" de la release.

Surtout que ca peut etre simple a faire… Si on peut avoir un fofo "Bugs 1.3" sur la preprod lors de la release, on a un endroit ou rassembler tout les rapports de bugs, les gérer et "compter les points" facilement. On aura un peu un "bounty challenge" a la google/facebook et consort mais en plus modeste et bonne franquette :D

Le forum dédié c'est un peu overkill non ? On pourrait utiliser ce fil pour ça et mettre à jour un tableau dans le premier post.

On organise un concours du meilleur chasseur de bug sur un weekend ? Le membre qui trouve le plus de bug sera érigé en héros dans l'article de présentation de la V1.3 (et on fait ca a chaque release) ?

On peut au moins le tenter une fois et voir l'impact !

chiche

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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