Les dates de releases sont cadrées et ça pousse à la roue, mais pour la qualité des releases est-ce qu’il ne faudrait pas aussi cadrer les conditions de release, pour éviter des régressions surprise et des bugs non invités ?
Actuellement j’ai l’impression que c’est au feeling : si ya pas de feedback ou de bug bloquant signalé ça passe – mais si ça se trouve personne n’a testé ou très peu ?
Pour cela les unit tests sont utiles mais insuffisants.
Pour bien faire, il faut tester en situation réelle,
avec des vrais utilisateurs avec les différents statuts (non logés, auteurs et admin).
Pour cela il faudrait établir la liste des sites (galaxie ou pas) où ç’a été testés.
faire une sorte de checkliste plus globalement,
et appliquer ces critères à chaque fois.
Les sites de la galaxie au moins ?
Pendant 3 semaines au moins ?
Quitte à plus partager la tâche car c’est du boulot à chaque fois
et donc les droits d’accès.
Oui, et ça rassure vu l’impact potentiel d’un dysfonctionnement de l’auth.
contrib.spip.net c’est bien fréquenté sur le public et dans le privé… mais c’est une configuration tellement particulière que quand ya un problème c’est pas facile de savoir quoi incriminer.
Notamment il y a le plugin offline et plein de plugins tant dans le public que le privé.
Là par exemple ya un problème sur le plugin crayon utilisé par le plugin gribouille dans le secteur Carnet Wiki pour les auteurs non connectés je crois : on ne peut pas savoir s’il faut en tirer une conséquence pour la version SPIP 4.1RC.
Ça induit une zone de flou et de tolérance aux problèmes rencontrés qui n’encourage pas leur signalement.
spip.net est plus proche de spip dist. Son espace public est bien fréquenté, mais il propose peu de formulaires ou d’interactions et sa partie privée est moins fréquentée. C’est complémentaire et ça permet(trait) de confirmer ou préciser les signalements.
Y aurait il d’autres sites en production qui testent les RC ? les beta ?
