Cela va bientôt faire deux semaines que spip-dev a été migré et a essuyé les plâtres. @fil me dit que la communauté spip en général est ok pour que les autres listes migrent, ce qui peut se faire techniquement ce week-end (j’ai un préférence pour le samedi). La checklist (dans l’ordre):
Mettre à jour discourse dont la dernière version stable 2.7.0 vient d’être publiée
Configurer discourse pour rester sur cette version stable et ses mises à jour mineures
Je pense que de nouveaux problèmes vont apparaître suite à cette migration parce que la population des utilisateurs a un profil différent. Je resterais à l’écoute des doléances relatives à des problèmes techniques mais il est probable que l’essentiel porte sur l’orientation sur l’interface web qui est peu familière.
Pour les personnes qui sont rebutées par cette migration et qui décident de quitter les listes je suggère de procéder comme pour cette demande et d’anonymiser puis désactiver le compte. Il y a cependant de grandes chances que la plupart des personnes choisissent simplement de cliquer sur le lien qui se trouve en bas de chaque courriel et qui permet de cesser de recevoir tout courriel en deux clicks et sans qu’il soit besoin de solliciter un·e admin.
Je tiens à vous remercier tous pour la bienveillance qui règne sur le forum depuis sa création et la patience avec laquelle vous avez fait face aux problèmes qui ont émergé. Croisons les doigts pour que cet esprit nous accompagne aussi dans la migration à venir. Ce n’est pas la traversée de l’atlantique, loin de la, mais garder le sourire et tenir le cap quand le bateau tangue c’est le genre d’aventure que j’aime
Super, merci @loic , pour être sur : d’après la liste des listes voici la liste des listes SPIP :
Fait :
spip-dev
A faire (pas de doute)
spip
spip-ann
spip-trad
Spip-de
spip-en
Spip-es
Ne pas transférer
spip-zone (puisque fusionnée avec spip-dev dernièrement)
Transférer ou pas ?
Spip-avec-escal
spip-commit
Spip-zone-commit
Spip-lille
Spip-paname
SPIP-Strasbourg
Spip-Toulouse
@fil il y a d’autres listes spip cachées ? (ou @loic tu as ptet accès ?)
pour lille/paname/strasbourg/toulouse : @fil peut confirmer que rien n’a été posté dernièrement sur ces listes qui correspondent à des listes locales qui étaient en place lors de la « grande époque » des apéros (meetup on dit maintenant) et que l’on peut les supprimer
Voici mes 2 cents .
Samedi c’est parfait et on fera un petit mail vendredi pour prévenir sur les listes qui sont transférées
A mon avis il faut un peu plus de delai entre le mails et la migration effective, pour laisser le temps au gens qui ne consultent pas la liste tous les jours de lire le mail
Non @maieul on n’a pas le temps de faire ça, il y a 700 listes à migrer sur le serveur .
Mais les abonnés continuent à recevoir les mails, il peut y avoir qqs bugs, mais il n’y a pas d’interruption de service.
La seule liste privée chez SPIP c’est spip-team qui vise surtout à gérer les trous de sécu. Je serais pour la migrer aussi, sachant que les contrôles d’accès sont bien gérés « en théorie » par les scripts de @loic, et qu’il faut bien qu’on se jette à l’eau là-dessus aussi.
Attention: si le courriel de destination est spip-zone, cela ne va pas arriver dans la catégorie spip-dev. Il ne peut y avoir qu’une seule adresse courriel par catégorie. Je vois en particulier le bot salvatore qui semble continuer à s’adresser à spip-zone (voir les rejetés https://discuter.spip.net/admin/email/rejected).
Samedi c’est bien de mon coté. Voici les listes dont j’ai connaissance:
spip-ann
spip-ar
spip-avec-escal
spip-commit
spip
spip-de
spip-dev
spip-en
spip-es
spip-herbier
spip-lille
spip-paname
spip-party-toulouse
spip-strasbourg
spip-team
spip-toulouse
spip-trad
spip-zone-commit
spip-zone
Par précaution je propose de solliciter une vérification manuelle (en ajoutant un message pour solliciter cette vérification par une personne sur cette catégorie) après création de la catégorie spip-team mais avant ingestion des archives. Ca évitera de mauvaises surprises.
Ravi de voir tout cela arriver rapidement (oui, j’ai été un peu grognon au début, mais je m’y fais très bien).
Concernant la liste spip-zone, j’ai rapidement cherché des messages que j’ai en archives sur mon poste en local et qui ne se retrouvent pas dans spip-dev - Discuter de SPIP
Non @maieul on n’a pas le temps de faire ça, il y a 700 listes à migrer sur le serveur
bon bah dans ces cas c’est vous qui décidez. Moi c’était juste une proposition alternative qui permettait de faire vite tout en laissant un peu de soufflerie.
spip-zone (puisque fusionnée avec spip-dev dernièrement)
Oui alors il y a transférer et transférer ça dépend ce qu’on entend
Car en effet, spip-zone a été fusionné « symboliquement » avec spip-dev, càd qu’on a en fait surtout coupé l’accès, et transféré les gens.
Mais le contenu des milliers de message (faisant une grosse base de connaissances et d’historique des devs de plugins), qui est une grosse partie du boulot de @loic, lui n’a pas été transféré du tout.
Du coup @loic est-ce que tu crois qu’il est possible d’importer dans la catégorie spip-dev du Discourse, tous les messages mail de la liste spip-zone ? Fusionner vraiment quoi. Ou bien juste sinon l’importer dans une autre catégorie dédiée « spip-zone » hein, qui sera fermée en écriture sur le forum ? (je n’ai pas d’avis sur la meilleure manière)
Je crois qu’il est inutile aussi de migrer les listes spip-party-toulouse et spip-toulouse
Si on reprend des apéros localement il sera toujours temps de créer quelque chose de nouveau
En important spip-zone on va récupérer les archives. Cela va créer une catégorie qui pourra ensuite (par exemple) être déplacée pour devenir une sous catégorie de spip-dev dans laquelle on pourra consulter toutes les archives et qui n’apparaîtra pas en catégorie principale. Fusionner avec spip demanderait d’écrire un script et risquer des envois de messages intempestifs donc c’est plus risqué et plus compliqué. Si la liste est fermée coté mailman et sans abonnés, l’import va en faire une catégorie fermée (écriture et abonnements) coté discourse et sans abonnés non plus.
Oui oui fait au plus simple, tu importes comme c’est prévu dans une catégorie dédié, et nous en admins du forum on fera les rangements/déplacements/fusions qu’on voudra après sans t’embêter !
Si la liste est fermée coté mailman et sans abonnés, l’import va en faire une catégorie fermée (écriture et abonnements) coté discourse et sans abonnés non plus.
Ok alors il faudrait vérifier ça avec les admins de la liste en question, vérifier qu’elle est bien fermée, et surtout vider les abonnés (qui normalement on déjà été transféré sur la liste spip-dev à l’époque et donc maintenant déjà ici).
Plutôt que d’avoir des noms de users aléatoires dans Discourse, comme
779ff40b979c2e4253ef, ce ne serait pas possible de prendre comme nom la
partie locale de l’email (local@domain.tld) s’il n’y a pas de nom côté
Mailman ?
je comprends l’idée, mais on a eu le cas de 2 jeanmarie avec spip-dev pour 500 abonnements, je crois, ça risque peut-être de compliquer la tâche de @loic la liste spip, c’est dans les 1200 abonnés, on va avoir beaucoup de cas d’homonymie …
J’avoue que c’est assez laid et peu pratique. Je me suis arraché les cheveux (enfin ce qu’il en reste) à trouver une solution. Il y a quelques éléments dans ce fil de discussion et l’algorithme choisi (et améliorable) se trouve ici. Pour faire court le problème c’est l’équilibre entre vie privée et lisibilité, combiné au fait que plusieurs listes ont des réglages différents pour une même personne et que cela peut être contradictoire quand on fait un import dans un seul forum.
Je suis très preneur d’une solution qui combine toutes les contraintes et qui évite ces noms d’utilisateurs vraiment pas jolis.
Je viens de penser que les utilisateur·rices abonnées à spip-dev qui ont aussi des comptes sur d’autres listes spip avec le même courriel vont voir leurs préférences de compte changer lors de la migration (comme cela a été le cas lors de la précédente mise à jour). Le plus gênant et visible étant le nom d’utilisateur qui va revenir dans certains cas à un hash. Les autres préférences sont listé ici.
faire la liste exhaustive des utilisateur·rice·s qui existent au début de l’import (la clé qui identifie un·e utilisateur·rice de façon unique est le courriel)
Comme les listes mailman sont totalement indépendantes les unes des autres, lorsqu’une personne est inscrite à plusieurs listes les préférences peuvent être différentes. Actuellement c’est la dernière liste migrée qui gagne. Avec cette option on filtre une partie de l’import.
C’est une modification assez légère que je devrais pouvoir faire et tester samedi matin et qui va utilement réduire le nombre de personnes surprises par le changement.
.