4 bugs ce matin (à vérifier et à traiter).
Merci de nous remonter vos tests sur Butterfly 1 le plus rapidement possible.
Le planning est très serré pour l'équipe.
8-)
Rappel:
Les versions intermédiaires ne sont pas prévues pour servir de base de départ à une migration vers une release officielle.
Ce qui signifie que si vous testez :
- une Butterfly (issue de la branche en cours de développement)
ou
- une RC (Release Candidate),
vous serez dans l'obligation de jeter le tout.
Pendant vos tests, vous découvrez un bug, vous l'ouvrez dans l'outil de suivi des Bugs. Merci.
Après votre test, supprimez les tables et le répertoire de votre test.
Et enfin télécharger la dernière version officielle disponible à partir du format que vous avez l'habitude d'utiliser.
Releases de PWG
Documentation des Releases ( Historique des releases ).
A chaque livraison d'une release candidate, les béta-testeurs sont prier d'installer la nouvelle release candidate et ...
de ne plus poster sur le forum avec une marqueur de l'ancienne release candidate mais avec le marqueur de la nouvelle.
Merci d'avance.
8-)
VDigital a écrit:
Merci VDigital, lui je l'ai trouvé, mais j'avais plus trop les yeux ouverts, donc je suis passé à côté du FIXME...
Promis, je recommence pas :-)
pour FIXME, j'ai cherché, mais je n'ai pas trouvé dans le guide de mise en page.
Je m'en souviendrais désormais!
mathiasm a écrit:
J'ai laissé un TODO car ça m'intrigue:
Dans les retours sur mantis, je ne comprends pas à quoi correspond le nom entre (). C'est le demandeur du retour ou celui qui doit répondre (dans le cas d'un membre, bien sûr)?
Le nom entre parenthèse est le développeur affecté à la fiche. Celui qui va modifier le code.
PS: dans le wiki, il vaut mieux utiliser FIXME, qui se transforme en icône automatique.
wiki updated. merci de vérifier si ça vous convient.
J'ai du coup élagué le chapitre dans la comm projet.
J'ai laissé un TODO car ça m'intrigue:
Dans les retours sur mantis, je ne comprends pas à quoi correspond le nom entre (). C'est le demandeur du retour ou celui qui doit répondre (dans le cas d'un membre, bien sûr)?
A mon avis, le mieux serait de faire une nouvelle page dans le wiki fr:bugtracker, qui fusionne les explications de fr:communication_projet#l_outil_de_suivi_des_bogues et celles du billet de mon blog.
Merci de ton aide :-)
ok.
Je peux, mais on fait une nouvelle page "Suivi des bogues pour les builds" ou on intègre ça dans la page "Versions et branches", § builds (en reliftant pour expliquer la perte des "BSF" dans le nom) ?
Pour ajouter un peu d'information, il y a quelques temps, j'ai donné les règles à suivre lorsque vous voulez notifier un bug découvert sur une release de test (RC ou build) sur mon blog : BSF et le suivi des bogues. Mon blog personnel n'est pas vraiment le meilleur endroit pour ce genre d'explication, donc il faudrait d'une façon ou d'une autre transférer ces informations sur le wiki.
Ancien titre: Règles d'utilisation des RC (Release Candidate) et builds
Les versions intermédiaires ne sont pas prévues pour servir de base de départ à une migration vers une release officielle.
Ce qui signifie que si vous testez :
- une Butterfly (issue de la branche en cours de développement)
ou
- une RC (Release Candidate),
vous serez dans l'obligation de jeter le tout.
Pendant vos tests, vous découvrez un bug, vous l'ouvrez dans l'outil de suivi des Bugs. Merci.
Après votre test, supprimez les tables et le répertoire de votre test.
Et enfin télécharger la dernière version officielle disponible à partir du format que vous avez l'habitude d'utiliser.
Releases de PWG
Documentation des Releases ( Historique des releases ).
A chaque livraison d'une release candidate, les béta-testeurs sont prier d'installer la nouvelle release candidate et ...
de ne plus poster sur le forum avec une marqueur de l'ancienne release candidate mais avec le marqueur de la nouvelle.
Merci d'avance.
Les autres posts ci-dessous concernent la documentation relative à ces points.
Ils peuvent être ignorés du simple utilisateur de Piwigo.
Merci.