Au début de l’année, nous annoncions le hackathon pour le vingtième anniversaire de Sympa (Système de multi‐postage automatique) sur ce site. Annonce qui avait posé question puisque Renater n’était alors pas associé à l’événement.
Si l’association de Renater est tardive, elle a été importante : l’organisme a en effet proposé et pris en charge la présence de David Verdin (meneur du projet de 2011 à 2016) lors de l’événement et a depuis aidé activement à transformer la gouvernance et le fonctionnement du projet vers son fonctionnement actuel (accès aux infrastructures et aux données relatives à la documentation, la traduction, l’hébergement du code source…).
Ainsi :
- GitHub héberge maintenant le code et le suivi de bogues (c’est expérimental), l’ancien système de suivi a été fermé ;
- Soji Ikeda (contributeur de longue date) est le nouveau responsable des publications, on compte huit publications (dont trois nouvelles versions stables) depuis le hackathon ;
- le site et la documentation sont en cours de refonte et utiliseront désormais les pages GitHub.
Nous avons au passage créé les canaux IRC #sympa et #sympa-fr sur freenode.
Cet été, c’est encore Renater qui finance le stage de Ludovic Muller (déjà contributeur) pour commencer l’implémentation de la maquette réalisée pendant le hackathon. Avec l’aide de Quentin, il expérimente l’utilisation de composants Web dans l’interface actuelle.
Ces mois de collaboration fructueuse avec Renater m’ont permis de découvrir une réelle volonté d’investissement dans le logiciel libre. C’est donc avec un immense plaisir que j’ai accepté la proposition qu’ils m’ont faite de les rejoindre. Je suis développeur Sympa et chargé de la valorisation et de la dynamisation du patrimoine open source de leur communauté depuis le 1er octobre.
Autre bonne nouvelle : David Verdin, est de retour à Renater depuis début septembre pour se consacrer à temps plein à Sympa, sa communauté et sa promotion. Avec presque deux ETP (équivalent temps plein), c’est la première fois depuis longtemps que le projet dispose de tels moyens permanents.
Comme le monde est petit, Guillaume Rousse (contributeur de Sympa, entre autres, lorsqu’il travaillait à l’Inria) a rejoint l’équipe sécurité de Renater.
Nous serons présents lors de l’Open Source Summit de Paris et probablement sur d’autres événements comme le FOSDEM et la prochaine Perl Conference.
# github
Posté par baobab . Évalué à 1. Dernière modification le 25 octobre 2017 à 15:26.
Voila une nouvelle bien sympathique.
Est ce que le passage à github a augmenté le nombre de contributions et celui des demandes d’améliorations?
Sympa est un projet qui commence à avoir de la bouteille, qu'en est-t-il de la dette technique?
[^] # Re: github
Posté par eiro . Évalué à 2.
ca n'est pas du gout de tout le monde (github ca pue c'est pas libre, tout ca …) mais c'était pragmatique et le release manager actuel (Soji) est très content de la situation actuelle. Il y a clairement plus de contributions sporadiques qu'avant mais je ne crois pas que ce soit simplement lié a github: le hackathon lui-même a amené de nouveaux contributeurs dans le projet.
perso j'ai pas d'avis ferme par rapport a github: par principe, j'étais plus attaché à sourcesup mais l'outils est clairement daté.
[^] # Re: github
Posté par scls19fr (site web personnel) . Évalué à 0.
HS : J'attend avec impatience le jour où SourceSup passera de FusionForge à une solution moins datée (Gitea, Gogs ou Gitlab avec une préférence pour le premier)… mais bon je ne suis qu'un utilisateur pas un mainteneur
[^] # Re: github
Posté par xseticon . Évalué à 1.
Par curiosité, qu'est ce que vous trouvez daté chez FusionForge ? Pour un environnement recherche où le suivi de version est encore souvent en SVN ou autre, est-ce que c'est possible d'utiliser ces alternatives (Gitea, Gogs, Gitlab) ?
[^] # Re: github
Posté par eiro . Évalué à 1.
je crois que toutes les solutions évoquées actuellement nécessitent un passage à git mais nous espérons faire ça bien en contactant les projets actifs, leur expliquer l'intéret qu'ils auraient à passer a git et les assister dans cette démarche (de la formation si besoin).
les avantages sont nombreux et dépendront de l'outils choisi mais si tu vas sur github par exemple, les fonctionnalités proposées pour voir l'état et l'activité de ton projet, créer des branches facilement, faire des pull requests, tagger les tickets sont clairement des choses qui aident la contribution.
ensuite: l'intégration de l'intégration continue et pe a terme du déploiement continu sont un énorme gain.
je te propose de t'inscrire sur libresup (https://groupes.renater.fr/sympa/info/suplibre), j'aimerais clairement y ouvrir le débat.
[^] # Re: github
Posté par eiro . Évalué à 1.
la seule chose que je peux te dire c'est que la discution est clairement en cours avec des gens qui poussent
[^] # Re: github
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Je ne sais pas pour Sympa, mais je peux dire que la migration à GitHub début de l'année a reboosté les contributions à CPython ! Je pense que c'est plus simple pour les contributeurs d'écrire une pull request et de la faire vivre jusqu'à ce qu'elle soit intégrée. D'ailleurs, les tests sont désormais lancés sur les pull requests, ce qui a beaucoup aidé !
[^] # Re: github
Posté par eiro . Évalué à 1.
c'est non seulement plus simple pour les contributeurs mais aussi pour nous: ils connaissent github et nous n'avons aucune doc spécifique à écrire, aucune assistance ou presque a faire.
# Les idées de design d'interface
Posté par Vincent-Xavier JUMEL (site web personnel) . Évalué à 4.
On peut trouver des mockups de la future interface publique et de l'interface utilisateur
[^] # Re: Les idées de design d'interface
Posté par jbv . Évalué à 3.
[HS] c'est quoi l'application utilisée pour faire les mockups de l'application ? Merci.
[^] # Re: Les idées de design d'interface
Posté par eiro . Évalué à 2.
un logiciel proprio sous mac qui s'appelle sketch. Quentin était clair là dessus: y'a juste pas d'alternative correcte
[^] # Re: Les idées de design d'interface
Posté par jbv . Évalué à 1.
OK, merci.
# Archives
Posté par gasche . Évalué à 8.
J'utilise plein de listes gérées par Sympa, et ça marche très bien, sauf les archives web qui sont presque inutilisables. C'est en particulier un point contentieux pour l'utilisation d'une mailing-list pour la communauté du langage OCaml, avec des membres qui demandent de passer à d'autres solutions (comme un forum web) à cause de la difficulté d'utilisation des archives. Entre autres:
suivre un thread ne marche pas dès que le thread est coupé sur deux mois, on ne peut pas passer d'un mois à l'autre en suivant le thread; la fonctionnalité est donc la plupart du temps inutilisable
la recherche est très difficile à utiliser correctement, en particulier elle va chercher seulement dans le dernier mois par défaut (du coup si on arrive sur une archive, on met comme chose à chercher dans la barre de recherche principale exactement le nom d'un topic un peu plus ancien, on va avoir un résultat vide)
Mon usage personnel des archives est de trouver un lien web pérenne pour faire référence à un mail envoyé sur la liste. Ce qui marche bien c'est de faire d'abord la recherche dans ma boîte mail, noter la date précise du mail, et ensuite aller chercher le mois correspondant dans l'archive Sympa — je pense que ce n'est pas optimal.
[^] # Re: Archives
Posté par eiro . Évalué à 4.
nous partageons complètement ton analyse … à tel point que je suis en train de plancher sur un nouvel archiver. si tu as des idées ou envie d'échanger: n'hésite pas à me contacter ou venir en discuter sur la liste https://listes.renater.fr/sympa/info/sympa-fr.
# Yunohost ?
Posté par Apichat (site web personnel) . Évalué à 2.
Un packaqge pour
était envisagé, où en est ce projet ?
[^] # Re: Yunohost ?
Posté par captainsqrt2 . Évalué à 2.
Salut,
il est disponible ici : https://github.com/YunoHost-Apps/sympa_ynh
Néanmoins la conclusion c'est que Sympa consomme beaucoup trop de RAM pour de l'auto-hébergement sur du "petit hardware" (type Raspberry Pi ou un VPS modeste). Il consomme 500 Mo de RAM en permanence sans rien faire… Donc pas généralisable au public type de YunoHost / La Brique.
J'ai ouvert un ticket sur le sujet ici : https://github.com/sympa-community/sympa/issues/24 - mais ça prendra probablement longtemps à être fixé …
En attendant, j'ai remis au propre l'app Mailman (2.x) avec ce que j'ai appris en faisant l'app Sympa : https://github.com/alexAubin/mailman_ynh
Le seul point noir de Mailman 2, c'est que l'interface web est affreuse. J'essaye de remédier à ça avec mes dogits boudinés ici : https://github.com/alexAubin/yololists
[^] # Re: Yunohost ?
Posté par eiro . Évalué à 3.
effectivement: pour le moment tout dans le code est pensé pour faire tourner de gros sites et YUnohost nous lance clairement un défi: faire tourner sympa sur un Pi.
d'un autre coté: les discutions qu'il y a eu pendant le hackathon autour de l'autohébergement et les fonctionnalités qui pouvaient en découler font que c'est un dossier qu'on va vraiment prendre en compte dans la refonte de sympa. Je n'espère rien de la branche actuelle.
[^] # Re: Yunohost ?
Posté par Apichat (site web personnel) . Évalué à 1.
Merci pour vos réponses :-)
[^] # Re: Yunohost ?
Posté par karchnu . Évalué à 1.
Je ne vois pas en quoi "faire tourner de gros sites" implique nécessairement de consommer beaucoup de ressources. D'autant plus à froid, sans une grosse charge. Qu'est-ce qui justifie cela dans votre application ?
[^] # Re: Yunohost ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
C'est un peu dommage d'avoir choisi Mailman 2 quand Mailman 3 est dispo et que son interface web est plus jolie ! Exemple au pif : l'interface web publique pour consulter les archives de la liste buildbot-status@python.org (une des premières à avoir migré à Mailman 3).
https://mail.python.org/mm3/archives/list/buildbot-status@python.org/
Pour avoir connu l'interface d'admin de Mailman 2, euh, je préfère carrément celle de Mailman 3. Pour info, on m'a dit que l'interface web ne permet pas encore de configurer tout ce que sait faire le backend.
[^] # Re: Yunohost ?
Posté par captainsqrt2 . Évalué à 1. Dernière modification le 26 octobre 2017 à 19:13.
Certes, Mailman 3 est plus joli que Mailman 2 ;)
Je ne l'ai pas testé moi-même, mais des retours que j'ai eu autour de moi, c'est aussi une usine à gaz difficile à déployer (pleins de modules différents), qui consomme beaucoup (j'ai entendu parlé de pics à 1 ou 2 Go de RAM) et destiné à traiter des quantités industrielles de mail (pas que ce soit négatif - ca réponds probablement à besoin, mais ce n'est pas celui de petits projets qui veulent juste 3 ML avec 50 gens max dessus).
[^] # Re: Yunohost ?
Posté par karchnu . Évalué à 1.
Est-ce que Sympa est plus simple à packager ? De ce que je vois de l'installation de Sympa, il y a une création d'un utilisateur système pour y mettre des fichiers dédiés à Sympa dans le home en incluant des binaires, notamment certains qui sont générés lors de la compilation de modules Perl qui doivent être installés à la volée, ce qui nécessite des bibliothèques de développement pour l'installation…
Pour bien faire il faudrait packager les différentes bibliothèques (ne pas rejouer l'installation à chaque fois, récupérant des bibliothèques dans des versions différentes à chaque fois), ne PAS créer un utilisateur dédié dans /home (c'est juste pas normal de fonctionner de la sorte, vous voyez d'autres softs UNIX demander la même chose ? Non. Et pour cause, c'est pas comme ça que ça fonctionne)… au final il faut patcher l'upstream qui ne respecte pas les conventions, et pas tenter de patcher un gestionnaire de paquets pour qu'il accepte de faire tout un tas de choses qu'il n'est pas censé faire.
Donc finalement, tu dis que mailman est une usine à gaz… moi j'en connais un autre. :-D
# Actualité du courriel en 2017
Posté par chimrod (site web personnel) . Évalué à 4.
Alors que l'on parle de plus des échanges à travers les applications de réseau social, comment se porte l'usage du courriel dans les listes de diffusion ? Est-ce qu'il y a encore des gros changements dans l'application, ou est-on passé sur un mode maintenance qui consiste plus en une correction des problèmes rencontrés ?
Est-ce qu'il est prévu des évolutions futures ?
[^] # Re: Actualité du courriel en 2017
Posté par eiro . Évalué à 3.
bon alors ca c'est clairement une question qui vaudrait un article sur mon blog … parceque c'est long et j'avoue ne pas avoir le temps de m'y consacrer immédiatement. mais en résumé très vite (et du coup ca pourrait paraitre naif comme ca …)
les réseaux sociaux sont soit centralisés et privés, soit décentralisés et pas ou peu adoptés. nous on pense que smtp est déjà un réseau social décentralisé qui manque d'une bonne interface web.
aujourd'hui les trolls sont réguliers pour savoir si les communautés doivent utiliser les web fora ou les messages pour communiquer. pour ce qui est de ma propre experience: je n'ai jamais vu la moindre interface web qui approche de pret ou de loin ce que je peux faire avec mutt/vim/(qq fonctions zsh) mais je comprend que nombre d'entre nous n'aie pas envie de se mettre à ce genre d'outils. il faut donc un systeme qui permettent les deux interfaces (mail et web) et pe plus encore. c'est ce qu'est deja sympa (page de post+archive) mais l'interface web est catastrophique: on compte changer ca
[^] # Re: Actualité du courriel en 2017
Posté par mzf (site web personnel) . Évalué à 2.
Peux-tu préciser ce que te permet ces outils par rapport à une interface web ?
Si c'est la recherche avancée, est-ce qu'un webmail type gmail n'est pas équivalent ?
[^] # Re: Actualité du courriel en 2017
Posté par Emmanuel Seyman . Évalué à 1.
Le top 3 en ce qui me concerne :
[^] # Re: Actualité du courriel en 2017
Posté par eiro . Évalué à 2.
au lieu d'avoir 20 interfaces sur lesquels il te faille te balader parceque tu participes à 20 listes différentes, tu a une seule interface parfaitement intégrée a tes outils (les memes abbréviations, completion et mappings partout la capacité de comparer facilement un bout de code d'une réponse avec la version que tu as dans ton repo (en mode diff), le fait d'avoir des bouts de reponse pretes a l'emploi dans le cas ou tu fais de l'assistance), que le tout soit extensible avec qq lignes de shell ou de viml de temps en temps … quelle interface graphique, aussi jolie soit-elle, ne me forcera a abandonner ce confort. et puis quand tu as l'habitude de vim, les textareas sont juste des plaies.
ca fait 20 ans que je me forge cet environnement a coup d'une ligne de conf de temps à autres et je me rend compte quand je fais le menage de temps en temps que ca fait 20 ans que ce systeme m'accompagne dans mes pratiques, mes macros ont evolué en fonction du job du moment pendant que d'autres allaient d'un outils à l'autre. cette régularité aussi, je l'apprécie parceque chaque nouvelle connaissance et experience est rentabilisée sur un long terme et donc gratifiante comme aucune interface web ne le sera jamais.
[^] # Re: Actualité du courriel en 2017
Posté par karchnu . Évalué à 1. Dernière modification le 02 novembre 2017 à 11:17.
La réponse se rapproche fortement de la différence entre un shell et une interface graphique. Tout réside dans l'extensibilité et la facilité d'usage. Étendre un webmail pour qu'en envoyant mon mail j'ai un script qui s'exécute, récupérer le résultat d'une commande, automatiser le reformatage d'un mail type pour afficher directement les informations que je recherche, faire ressortir des mots clés… bon courage.
La liste des possibilités est infinie avec un shell, sans faire de hack particulier, sans écrire du code spécifique à un webmail qui sera périmé à la prochaine version, sans réécrire le code du webmail, en ayant déjà tous les outils du shell à disposition, sans devoir modifier le code côté serveur…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.