Subject: Réflexion sur l'infrastructure de la liste

From: Jean Abou Samra <[email-masked]>
Date: Wed, 28 Jun 2023 21:33:06 +0200

Bonjour à tous,

J'aimerais ouvrir une discussion sur un sujet qui me paraît important,
à savoir l'infrastructure qui nous permet, communauté francophone de
LilyPond, d'être en contact et de nous entraider.

Ce mail est inhabituellement long, veuillez m'en excuser.

Depuis le départ, les interactions se sont faites sur cette liste de
diffusion, lilypond-user-fr, dont Valentin Villenave a toujours été
l'administrateur, rejoint par moi il y a quelques années. LilyPond
étant un logiciel rattaché au projet GNU, il était très naturel
d'utiliser une liste de diffusion par emails, comme la plupart des
autres projets GNU, et également comme la partie anglophone de la
communauté LilyPond (avec les listes lilypond-user, équivalent
anglophone de cette liste, ainsi que lilypond-devel, la liste des
développeurs, et bug-lilypond, la liste des rapports de bug ; par
contre la communauté germanophone a un forum Simple Machines,
https://lilypondforum.de).

Jusqu'à il y a quelques années, il était également possible de lire et
poster sur la liste à travers le portail Nabble plutôt que de recevoir
les mails, ce qui était jugé plus pratique par
certains. Malheureusement, Nabble a mis la clé sous la porte en 2021
(voir
https://lists.gnu.org/archive/html/lilypond-user-fr/2021-06/msg00133.html,
https://lists.gnu.org/archive/html/lilypond-user-fr/2021-07/msg00000.html,
https://lists.gnu.org/archive/html/lilypond-user-fr/2021-07/msg00064.html).
Suite à cela, j'ai cru comprendre qu'un certain nombre de personnes
étaient un peu déçues de devoir passer par les mails. J'ai essayé
de trouver une alternative à Nabble, sans succès. À l'époque,
je n'ai trouvé qu'un logiciel de forum (FUDforum) qui aurait pu être
une interface à une liste de diffusion existante, et il y avait des
problèmes techniques. Les autres nécessitaient de déménager la liste
entièrement.

Aujourd'hui, je me demande justement si un déménagement serait
souhaitable. D'un côté, je suis relativement attaché à
l'infrastructure des listes de diffusion GNU, notamment parce qu'elle
est sur pied sans interruption depuis plus longtemps que LilyPond
n'existe (plus de 20 ans), sans nécessiter aucune maintenance de notre
part, alors que dans le même temps, un certain nombre de sites liés à
LilyPond (je pense par exemple à lilynet.net, où il y avait autrefois
une liste de diffusion pour les traducteurs, ou encore lilybin.com ou
lilypondblog.org) ont fermé parce que leurs créateurs ou mainteneurs
n'étaient plus disponibles, comme il arrive à chacun. D'un autre côté,
je dois reconnaître que l'hébergement actuel comporte quelques
inconvénients notables.

- Les délais de distribution : parfois un message prend plusieurs
  heures voire plusieurs jours à arriver à tous les abonnés de la
  liste. C'est un problème récurrent sur les serveurs GNU, et les
  administrateurs du serveur n'ont pas beaucoup de temps pour s'en
  occuper (ils n'ont d'ailleurs pas beaucoup de temps en général).

- Le fait que les listes de diffusion sont un système un peu désuet :
  par exemple, j'ai aidé à quelques personnes qui ne comprenaient pas
  comment poster sur la liste.

- Il y a hélas des dysfonctionnements récurrents sur le serveur
  GNU. Il y a quelques jours par exemple, j'ai aidé un abonné qui ne
  recevait plus les messages à la liste, de manière
  inexplicable. Problème connexe : la liste tourne sous Mailman 2, un
  logiciel qui n'est plus pris en charge depuis belle lurette, Mailman
  3 étant la version actuelle. Avec Mailman 3, on aurait d'ailleurs un
  interface Web ressemblant à Nabble, mais malgré quelques discussions
  avec les administrateurs du serveur à ce sujet il y a plusieurs
  mois, je n'ai pas l'impression que le passage à Mailman 3 soit en route.

- Enfin, ce qui me peine le plus personnellement : les archives. Pour
  rappel, elles sont ici :
  https://lists.gnu.org/archive/html/lilypond-user-fr
  Non seulement elles ne sont pas très pratiques (quand la conversation
  s'étend sur plusieurs mois, il faut manuellement aller chercher la suite
  du fil de discussion dans les archives du mois suivant), mais surtout, la
  barre de recherche fonctionne très mal. Elle n'est déjà pas fameuse
  sur la liste anglophone, mais en plus, elle ne marche pas avec les
  caractères accentués. Les archives de la liste sont une mine d'or de
  solutions à des problèmes divers et variés, et je trouve vraiment
  dommage qu'elles ne soient plus utilisables dès que l'un
  des termes de recherche comporte un « é ».

Cela étant dit, les questions sur une éventuelle migration sont
multiples. Les plus immédiates sont : vers quel système ? Et comment
organiser la migration, pour éviter le pire qui serait de perdre une
partie de la communauté en route ?

Il y a de nombreux logiciels de forum de discussion. Je crois que le
plus répandu à l'heure actuelle pour les logiciels libres est
Discourse ; en tous cas, c'est le seul dont j'aie vraiment une
expérience à part les listes de diffusion, car il est utilisé dans
d'autres communautés liées aux logiciels libres que je suis de près ou
de loin, notamment la communauté Python anglophone
(https://discuss.python.org) et francophone (https://discuss.afpy.org)
ainsi que le projet GNOME (https://discourse.gnome.org) ou encore le
langage Rust (https://users.rust-lang.org,
https://internals.rust-lang.org). Il y a du bon et du mauvais dans
Discourse, je n'en suis pas fan inconditionnel (je pense au système de
« likes » qui ressemble un peu trop aux réseaux sociaux à mon goût,
même si c'est parfois utile), mais cela marche globalement plutôt bien
à mon sens. De plus, contrairement à certaines alternatives comme
Google Groups, c'est un logiciel libre. L'idée serait d'avoir un
serveur Discourse auto-hébergé. (Il faudra que deux ou trois personnes
soient administratrices du serveur, pour que ce ne soit pas une catastrophe
si l'une n'est plus disponible. 
https://fr.wikipedia.org/wiki/Facteur_d%27autobus )

Un point fort de Discourse est qu'il reste possible d'interagir avec
la liste exclusivement par mails, en s'abonnant aux notifications et
en y répondant (il y a aussi une adresse spéciale pour créer un
nouveau sujet). Dans un sens, cela correspond au logiciel idéal que je
cherchais il y a deux ans pour remplacer Nabble, sauf qu'on ne peut
pas garder l'adresse actuelle de la liste avec Discourse.

Dans l'hypothèse d'une migration, il faudrait que les archives
existantes soient transférées vers le nouveau système. C'est la partie
la plus compliquée, le reste étant a priori plus simple.

Il devrait aussi être possible de configurer le nouveau serveur pour
que tous les abonnés actuels aient un compte créé automatiquement et
reçoivent les notifications, de sorte à avoir une continuité.

On pourrait aussi demander des conseils dans d'autres communautés qui
ont opéré une migration similaire, comme Python et GNOME.

Soyons très clairs : même si je suis administrateur (avec Valentin,
que je n'ai toutefois pas vu depuis un moment), il est hors de
question que je prenne une décision dans mon coin et que je
l'applique. Si migration il y a, elle sera décidée collectivement. En
règle générale, dans les projets de logiciel libre, la méthode de
décision par consensus fonctionne très bien (discuter et voir si un
consensus émerge, ce qui est souvent le cas).

On ne va pas chercher à prendre une décision finale avant d'avoir
fait des tests sérieux, mais comme il y a malgré tout un certain nombre
de détails à comprendre, j'aimerais d'abord avoir une idée du sentiment
général vis-à-vis d'une migration éventuelle. Je veux juste éviter de passer
plusieurs jours cet été le nez dans le cambouis de Discourse pour me rendre
compte a posteriori que personne n'en veut.

Un dernier point. Bien sûr, tout ceci s'applique aussi à la liste
anglophone. Simplement, la migrer est encore une affaire d'un autre
ordre (elle a beaucoup plus d'abonnés), donc je pense qu'il est sage
que la communauté francophone fasse d'abord son choix indépendant. Si
nous migrons, avec le recul sur cette expérience, migrer les autres
listes deviendra plus raisonnable et pourrait se faire après
discussion sur ces listes.

N'hésitez pas à poser des questions et exprimer votre avis. Si vous
voulez vous faire une idée de l'interface de Discourse, vous pouvez
allez fouiner sur https://discuss.afpy.org (l'instance de
l'Association Francophone Python).

Cordialement,
Jean

---

From: Ya Gloops <[email-masked]>
Date: Wed, 28 Jun 2023 20:12:00 +0000 (UTC)

Bonsoir Jean !
Pour ma part, j'avais été déçu du passage de Nabble à cette liste de diffusion, car j'utilisais un lecteur de flux RSS...
Maintenant je télécharge les archives en mbox format, ce qui n'est pas si mal finalement...
Donc, si Discours fait les deux je signe tout de suite...
Gilles

Le mercredi 28 juin 2023 à 21:33:37 UTC+2, Jean Abou Samra <[email-masked]> a écrit : 

Bonjour à tous,

Cordialement,
Jean

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jun 2023 22:19:37 +0200

> aller fouiner sur https://discuss.afpy.org (l'instance de

Bonjour,

Excellente idée, je reste très attaché à la ML, en revanche faire une recherche sur les archives est une gageuse !

Mes premières impressions :

Les briques de “discourse” sont simples : 
https://discourse.org/about
https://github.com/discourse
- Ember.js
- Ruby on Rails
- Postgres
- Redis 

Au sein de notre société, nous hébergeons toute sorte de projets avec ces prérequis.
Donc, je vous propose mon aide, si vous le souhaitez, pour jouer le sys-admin.

En revanche, je suppose qu’il faudra coder la migration vers des archives de la liste.
Ce projet sera sympa !

Reste le problème du paiement de l’hébergement, faut-il constituer une association ?
Faut-il trouver des sponsors ?

Pour ce genre de projet, nous utilisons ce genre de serveur :
https://www.ovhcloud.com/fr/bare-metal/rise/rise-game-1/
Il faut un budget de 500 € par an, cela ne me semble pas inabordable.

---

From: Olivier Miakinen <[email-masked]>
Date: Wed, 28 Jun 2023 22:32:01 +0200

Bonjour Jean, bonjour à tous,

> Ce mail est inhabituellement long, veuillez m'en excuser.

Je vais donc supprimer pratiquement tout lors de ma réponse. J'ai l'habitude
(surtout dans les groupes de news) de répondre point par point aux phrases
auxquelles j'ai une réponse à apporter, mais pour une fois je préfère
répondre globalement.

Pour ma part, j'aime bien le principe de la liste de diffusion. Je préfère
ça aux forums webs, pour la raison suivante : comme je reçois chacun des
messages, je lis à peu près tout, au moins le sujet et les premières lignes.
Ainsi, les rares cas où je peux être utile, ça me permet de ne pas passer
à côté.

D'après ce que tu dis Discourse permettrait les deux à la fois, même si je
suis dubitatif à propos de l'« adresse spéciale » pour créer un nouveau
sujet.

Pour le reste :
1) En tant qu'utilisateur de LilyPond, je suis bien sûr à 100 % favorable
 au fait de privilégier un logiciel libre.
2) S'il y a besoin d'aide, et dans la mesure de mes compétences et de mon
 temps libre, je peux être volontaire pour contribuer au transfert des
 archives ou (inclusif) à l'administration de la liste.
3) Faire essuyer les plâtres à la liste francophone avant de migrer la
 liste anglophone ayant beaucoup plus d'abonnés me semble une bonne idée.

Cordialement,
-- 
Olivier

---

From: Jean Abou Samra <[email-masked]>
Date: Wed, 28 Jun 2023 23:30:30 +0200

Le mercredi 28 juin 2023 à 20:12 +0000, Ya Gloops a écrit :
> Bonsoir Jean !
> Pour ma part, j'avais été déçu du passage de Nabble à cette liste de
> diffusion, car j'utilisais un lecteur de flux RSS...

On peut effectivement suivre un forum Discourse par RSS.

À ma connaissance, il n'y a pas d'interface pour télécharger les messages en
mbox. Par contre, on peut choisir de recevoir des messages groupés. La liste
permet de recevoir un message groupé par jour, Discourse permet de choisir entre
un par jour, un par semaine, un par mois et un tous les 6 mois (exemple en pièce
jointe).

Cordialement,
Jean

Subject: [Rust Internals] Summary
From: Rust Internals <[email-masked]>
To: [email-masked]
Date: Fri, 19 May 2023 21:39:16 +0000

A brief summary of [Rust Internals][1] since your last visit on May 12

20 New Topics
26 New Users

--------------------------------------------------------------------------------

### Popular Topics

[`<[T]>::[array_]windows` (and chunks?) function family could allow 0 length][2]

 I got this idea from reading the discussion in Make `<[T]>::array_*` methods fail to compile on 0 len arrays by AngelicosPhosphoros · Pull Request #99471 · rust-lang/rust · GitHub about how to forbid 0 as length for <[T]>::array_windows. I don't have enough knowledge to comment on the original topic, but it got me thinking: why do we forbid 0 in the first place? 
There is a mathematically consistent implementation for <[T]>::[array_]windows(0). Let's take a look at some other input: 
[0, 1, 2].windows(3) -> [ [0, 1, 2] ];              iterator length = 1, window length = 3
[0, 1, 2].windows(2) -> [ [0, 1], [1, 2]];          iterator length = 2, window length = 2
[0, 1, 2].windows(1) -> [ [0], [1], [2] ];          iterator length = 3, window length = 1

(edit: fixed some off-by-1 error above)
and if we extrapolate this, we get 
[0, 1, 2].windows(0) -> [ [], [], [], [] ];         iterator length = 4, window length = 0

So a valid implementation of [_; N].windows(0) is to return an iterat...
--------------------------------------------------------------------------------

[Pre-RFC: Storage API][3]

 Quick Introduction
If you already know about the Storage API, and its motivation, feel free to skip this section. 
The key idea of the Storage API is that the Allocator API is just not good enough for a variety of situations: 

Allocators cannot allocate memory in-line, so ad-hoc solutions such as ArrayVec are necessary instead... which is good and all, but who here wants to re-implement hashbrown?
Allocators cannot be used in const contexts, so we can't have non-empty collections in const or static contexts. Not directly, anyway.
Allocators cannot be used with shared memory, and possibly not with segmented memory (GPUs? I don't know much about those...).

So, what if we had an Allocator-like API, which didn't suffer from these limitations? This is what the Storage API hopes to be. 

Brief History
Once upon a time (2 years ago) I publicized a repository called storage-poc in order to present an alternative, or a supplement, to the Allocator API. This repository was not quite suitable ...
--------------------------------------------------------------------------------

[Making Rust core and alloc panic free][4]

 I have been working with Rust in embedded contexts for a while now. While I absolutely love the rust compiler and borrow checker, I am still not completely sold on Rust panics. 
I do understand panics in Rust std; they make the language a lot better to work with. However, I do not like the existence of implicit panics in core and alloc. Generally, Rust panics should be used in unrecoverable situations. It easier to argue which situations can be considered as unrecoverable in the context of Rust std since the targets that support std are limited and mostly have some underlying system. 
The core and alloc (to some extent) seem to be present to allow using Rust where only basic C or similar low-level language can be used. However, this also means it is challenging to use make assumptions of what these use cases entail. The best example I can think of is allocation error. It might be unrecoverable in case you are writing something to run on an OS. However, when writing an OS or firmware it...
--------------------------------------------------------------------------------

[An alternative to the current `Unpin` hack:`UnsafeAlias`][5]

 One way to allow self-referential structs would be a new type UnsafeAlias, which allows a pointer and a mutable reference to overlap. The proposed api would be: 
impl<T:?Sized> UnsafeAlias<T>{
    pub fn new(value:T) where T:Sized ->Self
    pub fn as_ref(&self)-&T
    pub fn from_ref(reference:&T)->&Self
    pub fn from_mut(reference:&mut T)->&mut Self
    pub fn into_inner(self)->T where T:Sized

    ///Safety:The returned pointer is safe to read from but can cause undefined behaviour 
    ///if written to(unless the data written to is inside an `UnsafeCell`)
    pub fn get_ptr(&mut self)->*const T
}

impl<T:?Sized> !Unpin for UnsafeAlias<T>{} 

This would allow self-referential structs and async functions while still allowing optimisations on shared references. On an llvm level, the only change would be removing the noalias annotation on mutable references pointing to a type containing a UnsafeAlias ;Shared references can remain noalias readonly(assuming the type does not contain a U...
--------------------------------------------------------------------------------

[Why not a `ArrayStr<N>` for `str` as array for slice in std?][6]

 Indeed. It didn't used to be that way before Rust 1.0, but this RFC changed it: 0339-statically-sized-literals - The Rust RFC Book 
See also: B in bstr - Rust
--------------------------------------------------------------------------------

### Popular Posts

withoutboats - [Runtime-agnostic cooperative task scheduling budget][7]

 (NOT A CONTRIBUTION) 

Yea, these are clearly two forces in tension in any project. But I feel very comfortable saying which of these forces the Rust project is too biased towards. 

This isn't quite a correct recounting. 
We got rid of LocalWaker and just went with Waker on the basis that single threaded executors can use arrays and indexes. At the time our narrative around single threaded executors was that they were strictly for embedded systems that wouldn't want to use an Rc waker anyway. Of course, the renewed interest in thread-per-core has shown this is wrong. 
But this all happened before Context was added. Adding Context was fully driven by the tokio project, as future proofing to support exactly the kind API I'm proposing now. Frankly, within the async WG we didn't think it was necessary, and really forfeited this discussion in order to get buy in on shipping. So the reason Context wasn't Send + Sync was a total oversight, probably in large part because we thought it was unn...
--------------------------------------------------------------------------------

steffahn - [`<[T]>::[array_]windows` (and chunks?) function family could allow 0 length][8]

 I agree with the general assessment that this might be the case, but nonetheless it would be interesting to find some concrete example of “algorithms(s) built on top of windows” to see whether this will actually handle edge cases of any reasonable, practical algorithms :slight_smile: 

The chunks case on the other hand sounds a bit too much like division by zero, in particular, [].chunks(0) seems hard to define in any particularly nice way, just as dividing zero by zero (whereas for positive numbers divided by zero, the answer “(positive) infinity” is – at least – the unique answer following limit arguments). The obvious problem is that [].chunks(n) is always empty, whereas […non-empty…].chunks(0) is always infinitely long, so you have an argument for [].chunks(0) to be empty, but also an argument for it to be infinitely long (and possibly, by some different “limit”-style argument, you can also argue for anything in-between). 
Another interesting effect of defining both chunks and win...
--------------------------------------------------------------------------------

bascule - [Making Rust core and alloc panic free][9]

 Hypothetically if core/std had a mechanism like Cargo features (ala the std-aware Cargo work), one of the on-by-default features could be panic. 
Disabling the feature could disable the entire panic subsystem and any APIs which use it. 
This would be particularly nice as a way of ensuring code is panic-free: instead of linting code with "panic detectors", anything that causes a panic would become a compile error. 
This is beneficial for many environments where panics are considered an antifeature, including the aforementioned embedded space, but also the Linux kernel.
--------------------------------------------------------------------------------

scottmcm - [`<[T]>::[array_]windows` (and chunks?) function family could allow 0 length][10]

 I would consider this one unacceptable, because to me one essential property of chunks is that .chunks(n).flatten() recovers the original.  (And .chunks_exact(n).flatten() recovers the original other than potentially fewer than n missing from the end.)
--------------------------------------------------------------------------------

withoutboats - [Runtime-agnostic cooperative task scheduling budget][11]

 (NOT A CONTRIBUTION) 
Anyway, I can't drive this idea any further than this thread. If anyone reading is excited by this idea, please do take it on.
--------------------------------------------------------------------------------

**New for you**

* [[Pre-RFC] Unify references and make them generic over mutability][12] - 16 - [language design]
* [Opting out of lifetime invariance in opaque types][13] - 3 - [language design]
* [Better error when trait not implemented because of different crate version][14] - 3 - [traits working group]
* [Cargo should detect changes in dependency source files][15] - 3 - [cargo]
* [Expose symlink_junction][16] - 1 - [libs]

[1]: https://internals.rust-lang.org/
[2]: https://internals.rust-lang.org/t/t-array-windows-and-chunks-function-family-could-allow-0-length/18815
[3]: https://internals.rust-lang.org/t/pre-rfc-storage-api/18822
[4]: https://internals.rust-lang.org/t/making-rust-core-and-alloc-panic-free/18826
[5]: https://internals.rust-lang.org/t/an-alternative-to-the-current-unpin-hack-unsafealias/18810
[6]: https://internals.rust-lang.org/t/why-not-a-arraystr-n-for-str-as-array-for-slice-in-std/18834
[7]: https://internals.rust-lang.org/t/runtime-agnostic-cooperative-task-scheduling-budget/18796
[8]: https://internals.rust-lang.org/t/t-array-windows-and-chunks-function-family-could-allow-0-length/18815
[9]: https://internals.rust-lang.org/t/making-rust-core-and-alloc-panic-free/18826
[10]: https://internals.rust-lang.org/t/t-array-windows-and-chunks-function-family-could-allow-0-length/18815
[11]: https://internals.rust-lang.org/t/runtime-agnostic-cooperative-task-scheduling-budget/18796
[12]: https://internals.rust-lang.org/t/pre-rfc-unify-references-and-make-them-generic-over-mutability/18846
[13]: https://internals.rust-lang.org/t/opting-out-of-lifetime-invariance-in-opaque-types/18811
[14]: https://internals.rust-lang.org/t/better-error-when-trait-not-implemented-because-of-different-crate-version/18808
[15]: https://internals.rust-lang.org/t/cargo-should-detect-changes-in-dependency-source-files/18831
[16]: https://internals.rust-lang.org/t/expose-symlink-junction/18809

This summary is sent from [Rust Internals][1] when we haven't seen you in a while. Change [your email settings][17], or [click here][18] to unsubscribe.

[17]: https://internals.rust-lang.org/my/preferences/emails
[18]: https://internals.rust-lang.org/email/unsubscribe/90f9b880ec66f3abda613b610ff37d5f925c334d66527f0d8bb42d75263338f0

---

From: [email-masked]
Date: Thu, 29 Jun 2023 00:31:29 +0200 (CEST)

Bonsoir à tous,

Je ne suis pas un informaticien de votre niveau, j'ai compris l'essence du problème, même si je ne comprends pas tous les termes de la question de départ ^^'

Personnellement, pour ma pratique quotidienne de lilypond, j'ai besoin d'échanger avec vous tous.

Donc, peu importe pour moi où et comment fonctionnera cette liste à l'avenir, j'en serai !

Je suis prêt à changer toutes mes habitudes, car j'ai besoin de la communauté, quelle que soit soit la forme qu'elle prend

Ma préférence va quand même pour un logiciel qui nécessiterait le moins de temps de gestion et d'administration 

Effectivement, on voit moins valentin sur la liste, et qui sait si un jour Jean (ou d'autres) n'aura pas d'autres obligations (la vie est ainsi faite...)

Bref, limiter les actions chronophages qui n'ont pas de lien direct avec lilypond ?

Mes connaissances en informatique étant insuffisantes, je fais pleinement confiance à Jean et aux connaisseurs de la communauté pour choisir une infrastructure qui permettra que la liste vive sur le long terme...

D'un point de vue pratique, je suis comme le mail précédent, c'est à dire que j'aime bien le fonctionnement par e-mail.

Que je sois intéressé ou non par la question, je suis sûr de tout lire (parfois en diagonale, mais je peux me faire une petite idée du sujet et y revenir plus tard si besoin)

Je récupère beaucoup d'astuces sans forcément répondre sur la liste (pour ne pas alourdir les échanges)

Ma pratique de la liste est la suivante :

-> Les messages étant essentiellement du texte (donc légers), ma recherche dans les archives se fait d'abord et surtout dans ma boite mail (recherche par mot clé : ah tiens, je me souviens avoir vu passer tel sujet, je vais rechercher la discussion dans mes mails)

-> quand j'ai cherché 10 fois la même astuce, j'ai l'idée de le copier dans mon fichier des astuces courantes à retenir...

-> Au sujet de la documentation de lilypond, je galère un peu car je n'ai jamais le bon mot-clé pour la barre de recherche (je sais que la page existe car je me souviens l'avoir déjà consulté, mais je perds beaucoup de temps pour la retrouver)

-> je ne consulte qu’exceptionnellement  les archives en ligne, et dans le cas ou je tombe sur une page d'archives, ça me rappelle une discussion que j'ai forcément dans mes mails et je retourne dans ma boite mail (mes mails sont triés par discussions, donc plus pratiques à consulter)

Je ne sais pas si ma réponse à la question est hors-sujet, mais il m'a semblé comprendre que Jean souhaitait des retours d'expérience d'utilisation de la liste...

Bonne soirée à tous, et encore un grand merci à tous ceux qui prennent du temps pour que la liste existe et que l'on puisse se poser ce genre de questions !

Raphaël

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 01:03:53 +0200

Bonjour,

> > Ce mail est inhabituellement long, veuillez m'en excuser.
[...]
> Ainsi, les rares cas où je peux être utile, ça me permet de ne pas passer

Personnellement, je ne lis mes infos que via le mail (read-write), ou des flux 
RSS (mais là c'est read-only). Je suis donc comme Olivier absolument favorable
à garder une vraie liste de diffusion.

Perso, les listes que j'administre sont sous Sympa
(https://www.sympa.community/) que j'utilise depuis 20+ ans. Il porte
bien son nom, pas trop de maintenance, le travail se faisant au setup
d'une nouvelle liste. En revanche, il ne faut pas négliger la conf du
serveur SMTP derrière et notamment, maintenant avoir un DKIM/DMARC
semble obligatoire pour bien fonctionner. Je suis justement en train de
le faire avec ansible pour mes listes, après mes domaines.
Il est aussi utilisé par Framasoft pour son service de listes (mais pas
adapté ici car ne gardant pas d'archives).

mailman est l'autre éléphant dans la pièce et avoir une instance
mailman3 faciliterait certainement aussi la migration.

> suis dubitatif à propos de l'« adresse spéciale » pour créer un nouveau

J'ai des doutes sur Discourse: https://meta.discourse.org/t/email-support-with-discourse/168483
Il faut qu'il puisse faire SMTP sinon, cela ne sera pas vraiment pareil
je pense...

>  au fait de privilégier un logiciel libre.

+1000 ;-)

>  archives ou (inclusif) à l'administration de la liste.

Idem.

>  liste anglophone ayant beaucoup plus d'abonnés me semble une bonne idée.

Tout pareil, pfff décidément jamais moyen de se fâcher avec Olivier
depuis nos années de promo ingé ensemble !!

Cordialement,
Bruno.
-- 
Des infos sur la musique ancienne  -- http://www.musique-ancienne.org
Des infos sur les logiciels libres -- http://www.HyPer-Linux.org
Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, 
Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)

---

From: "bernard.j.barbier" <[email-masked]>
Date: Thu, 29 Jun 2023 08:36:46 +0200

Bonjour !Merci Bruno pour le "il porte bien son nom".Ça faisait longtemps que je n'avais pas eu un compliment pareil !Car s'il s'appelle comme ça parce que c'est moi qui l'a nommé. Avec une release majeure de TulP, on a décidé du renommage, ça devait être en 1998 ou 1999.Sympa veut dire : SYstème de Multi Postage Automatique. Voili, voilà !Belle journée à tous, Papy.Message court, car envoyé depuis mon téléphone !😉
-------- Message d'origine --------De : Bruno Cornec <[email-masked]> Date : 29/06/2023  01:04  (GMT+01:00) À : Olivier Miakinen <[email-masked]> Cc : [email-masked] Objet : Re: Réflexion sur l'infrastructure de la liste Bonjour,Le Wed, Jun 28, 2023 at 10:32:01PM +0200, Olivier Miakinen a écrit :> Le 28/06/2023 21:33, Jean Abou Samra a écrit :> > > > J'aimerais ouvrir une discussion sur un sujet qui me paraît important,> > à savoir l'infrastructure qui nous permet, communauté francophone de> > LilyPond, d'être en contact et de nous entraider.> > > > Ce mail est inhabituellement long, veuillez m'en excuser.> [...]> Pour ma part, j'aime bien le principe de la liste de diffusion. Je préfère> ça aux forums webs, pour la raison suivante : comme je reçois chacun des> messages, je lis à peu près tout, au moins le sujet et les premières lignes.> Ainsi, les rares cas où je peux être utile, ça me permet de ne pas passer> à côté.Personnellement, je ne lis mes infos que via le mail (read-write), ou des flux RSS (mais là c'est read-only). Je suis donc comme Olivier absolument favorableà garder une vraie liste de diffusion.Perso, les listes que j'administre sont sous Sympa(https://www.sympa.community/) que j'utilise depuis 20+ ans. Il portebien son nom, pas trop de maintenance, le travail se faisant au setupd'une nouvelle liste. En revanche, il ne faut pas négliger la conf duserveur SMTP derrière et notamment, maintenant avoir un DKIM/DMARCsemble obligatoire pour bien fonctionner. Je suis justement en train dele faire avec ansible pour mes listes, après mes domaines.Il est aussi utilisé par Framasoft pour son service de listes (mais pasadapté ici car ne gardant pas d'archives).mailman est l'autre éléphant dans la pièce et avoir une instancemailman3 faciliterait certainement aussi la migration.> D'après ce que tu dis Discourse permettrait les deux à la fois, même si je> suis dubitatif à propos de l'« adresse spéciale » pour créer un nouveau> sujet.J'ai des doutes sur Discourse: https://meta.discourse.org/t/email-support-with-discourse/168483Il faut qu'il puisse faire SMTP sinon, cela ne sera pas vraiment pareilje pense...> Pour le reste :> 1) En tant qu'utilisateur de LilyPond, je suis bien sûr à 100 % favorable>  au fait de privilégier un logiciel libre.+1000 ;-)> 2) S'il y a besoin d'aide, et dans la mesure de mes compétences et de mon>  temps libre, je peux être volontaire pour contribuer au transfert des>  archives ou (inclusif) à l'administration de la liste.Idem.> 3) Faire essuyer les plâtres à la liste francophone avant de migrer la>  liste anglophone ayant beaucoup plus d'abonnés me semble une bonne idée.Tout pareil, pfff décidément jamais moyen de se fâcher avec Olivierdepuis nos années de promo ingé ensemble !!Cordialement,Bruno.-- Des infos sur la musique ancienne  -- http://www.musique-ancienne.orgDes infos sur les logiciels libres -- http://www.HyPer-Linux.orgHome, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 08:57:23 +0200

Bonjour,

> Donc, je vous propose mon aide, si vous le souhaitez, pour jouer le sys-admin.

Merci ! Si je me lance dans les tests, je verrai si j'ai besoin d'aide. A
priori, la partie sysadmin n'est pas la plus compliquée, mais c'est toujours ce
qu'on dit avant de l'avoir fait pour de vrai :-)

> En revanche, je suppose qu’il faudra coder la migration vers des archives de

Oui, c'est la partie la plus compliquée, je crois qu'il existe des outils pour
cela mais il faudra voir à quel point ils fonctionnent bien.

> Il faut un budget de 500 € par an, cela ne me semble pas inabordable.

Une association est une idée intéressante, mais je pense qu'on n'en aura pas
forcément besoin juste pour le financement du serveur. Les Allemands, avec leur
forum Simple Machines, se cotisent un peu de manière informelle (à ce que j'ai
compris).

Cordialement,
Jean

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 29 Jun 2023 09:09:08 +0200

> Le 29 juin 2023 à 08:57, Jean Abou Samra <[email-masked]> a écrit :
> 
> Le mercredi 28 juin 2023 à 22:19 +0200, [email-masked] <mailto:[email-masked]> a écrit :
> Une association est une idée intéressante, mais je pense qu'on n'en aura pas forcément besoin juste pour le financement du serveur. Les Allemands, avec leur forum Simple Machines, se cotisent un peu de manière informelle (à ce que j'ai compris).

L’association même avec un fonctionnement léger, reste une machine administrative avec au moins deux personnes ;-)
En revanche, elle permet la déduction fiscale des dons (un peut plus d’administration automatisable par hello-asso, par exemple). 
Le second point est que l’association possède un compte bancaire pour y effectuer les prélèvements. Ainsi cela ne repose pas sur une personne et sur ces finances personnelles.

Je reconnais que j’aime beaucoup la déduction fiscale ;-)
Philippe

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 09:36:28 +0200

> suis dubitatif à propos de l'« adresse spéciale » pour créer un nouveau

Je crois que j'ai été un peu vague et qu'il faut que je précise les choses à ce
niveau-là.

Pour recevoir tous les posts par mail, l suffit de cocher une case « Mode
mailing list » dans les préférences (il devrait y avoir moyen, je l'espère,
qu'elle soit cochée pour tous les comptes qui seront migrés depuis la liste
actuelle).

On peut répondre directement à chaque post reçu par mail, comme on le ferait sur
cette liste.

Si les administrateurs l'ont configuré (ce qui serait évidemment fait dans le
cas présent), on peut aussi créer un nouveau sujet via une adresse mail qui
ressemble à l'adresse actuelle de la liste.

Une différence avec le fonctionnement de la liste actuelle est que ce n'est pas
la même adresse pour créer un nouveau sujet et pour répondre. En fait, pour les
réponses, l'adresse est unique à chaque fois (ce n'est que de la spéculation,
mais j'imagine que c'est pour pouvoir rattacher de manière fiable la réponse à
un sujet, même en présence de mauvais clients mail qui ne répondent pas avec les
en-têtes corrects pour garder le sujet).

De plus, quand on répond, il n'y a qu'une seule adresse à laquelle répondre (qui
est dans l'entête Reply-To). On n'a pas l'adresse de l'auteur du post (et
d'ailleurs, on peut utiliser une instance Discourse sans que les autres ne
voient son adresse mail). À vrai dire, je préfère cela : sur les mailing lists,
il est courant d'envoyer une réponse en privé par erreur, en cliquant sur «
Répondre » au lieu de « Répondre à tous »… Par contre, il y a l'inconvénient
qu'il faut passer par l'interface Web pour envoyer une réponse privée (mais on
reçoit les réponses privées adressées à soi par mail tout comme les posts
normaux).

Les mails reçus ont à la fois une partie HTML et une partie texte. La partie
texte est lisible bien que pas optimale. Je mets un exemple de mail reçu en
pièce jointe.

Dans l'interface Web, il y a une syntaxe à la Markdown pour le formatage du
texte (*italique*, **gras**, `code`, etc.). Il faudrait que je me renseigne pour
savoir si une réponse par mail en texte brut se voit aussi appliquer ce
formatage.

Personnellement, j'ai suivi pendant plusieurs mois l'instance de Python par mail
et je n'ai pas rencontré de problème particulier.

Est-ce que cela est plus clair ?

>  archives ou (inclusif) à l'administration de la liste.

Merci à toi !

Cordialement,

Jean

Subject: [Py] [Core Development] Formalize the concept of "soft deprecation" (don't schedule removal) in PEP 387 "Backwards Compatibility Policy"
From: "Paul Moore via Discussions on Python.org" <[email-masked]>
To: [email-masked]
Date: Fri, 16 Jun 2023 11:34:29 +0000
List-Id: Discussions on Python.org | Core Development <core-development.discuss.python.org>

[quote="Jean Abou Samra, post:2, topic:27957, username:jeanas"]
I like the concept of “soft deprecating”, but please don’t use `PendingDeprecationWarning` for it.
[/quote]

Agreed. I don't think soft deprecations should emit *any* sort of warning, they should be "documentation only".

Pip uses optparse. We cannot change to argparse, because it doesn't support some CLI syntaxes that we use (don't ask me what, I can't recall). We have talked about switching to a more modern CLI parser like click, but it would be a significant job, and it's *very* low on our priority list. People use pip with warnings turned into errors. We don't necessarily like this, but they do, and we get bug reports as a result. We could of course suppress any warning that gets added, but that's just busy-work.

After all, a "soft deprecation" warning *isn't actionable*. The end user can't do anything, and the developer has no required timescale to make any change. So what's the action that the warning would be prompting? The only impact of a soft deprecation is "don't use in new projects". But it's not possible to determine programmatically if a use is "in a new project", so it's not possible to make an appropriate choice about issuing a message.

By all means, let's create a clear definition of what "soft deprecation"[^1] means. And having a standard paragraph that can be used in the docs for anything that is soft deprecated seems like a good idea, as it gives a very consistent message. But *please*, let's not alter the behaviour of running code that uses features that are *only still there to avoid breaking running code in the first place*!

[^1]: I don't like that term, but let's bikeshed later.

---
[Visit Topic](https://discuss.python.org/t/formalize-the-concept-of-soft-deprecation-dont-schedule-removal-in-pep-387-backwards-compatibility-policy/27957/5) or reply to this email to respond.

To unsubscribe from these emails, [click here](https://discuss.python.org/email/unsubscribe/8ecedab3f17c0d5a091676394baaac7dd61c9b461360cf2228bd66b707cdbac7).

---

From: Olivier Miakinen <[email-masked]>
Date: Thu, 29 Jun 2023 09:55:05 +0200

> Je crois que j'ai été un peu vague et qu'il faut que je précise les choses à ce

Merci ! ;-)

> en-têtes corrects pour garder le sujet).

Alors là j'ai une crainte assez forte à propos de ce fonctionnement, et
toi qui as déjà une expérience de ce type de liste pourrais dire ce qu'il
en est en réalité.

Ma crainte, c'est que l'immense majorité des gens ayant une nouvelle
question à poser ne prennent pas la peine de le faire sur cette adresse
secondaire, et qu'ils se contentent de la poser en réponse à un sujet
précédent qui n'a strictement rien à voir. C'est déjà parfois le cas avec
la liste actuelle malgré l'absence d'une telle contrainte, alors j'ai du
mal à imaginer qu'on puisse l'éviter avec ce fonctionnement à deux adresses.

> Répondre » au lieu de « Répondre à tous »…

Oui, là je suis d'accord avec toi.

> texte est lisible bien que pas optimale. Je mets un exemple de mail reçu en

En effet. La citation sous forme de markup « [quote] ... [/quote] » est
moins lisible dans un courrielleur que le système avec chevrons. Et je
suppose que c'est encore pire s'il y a deux niveaux de citation.

> Est-ce que cela est plus clair ?

Oui, parfaitement. Merci de ces précisions.

-- 
Olivier

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 09:58:52 +0200

> mailman3 faciliterait certainement aussi la migration.

C'est vrai qu'il y a Sympa et Mailman.

Dans Mailman 3, l'interface des archives permet de poster comme je le disais.
Par contre, cela ne fait qu'ouvrir une fenêtre dans un client mail (exemple
: https://mail.python.org/archives/list/[email-masked]/thread/HNFVMG3L577ZFLBDH2Y54J7KGLUWTLEL/
 ). En particulier, pas de citation facile du message auquel on répond, par
exemple.

Pour Sympa, je voulais tester, mais
sur https://lists.sympa.community/compose_mail/en/html_news_letter , je lis «
Posting from Web interface is closed for now ». Bernard, est-ce que vous savez
si c'est temporaire ?

Dans l'ensemble, en gardant une mailing list, on continue d'avoir un système qui
ne coule pas forcément de source pour ceux qui ne connaissent pas les mailing
lists, mais on gagne des archives plus utilisables et un serveur qui
fonctionnerait mieux, avec une migration probablement plus simple vu que la
nouvelle liste acceptera sans doute les mbox des archives précédentes. Ça peut
s'envisager...

Il faut peut-être que je parle d'un facteur que j'ai oublié dans mon message
initial : je constate que pas mal de discussions liées à LilyPond (mais surtout
en anglais) se font en dehors des mailing lists sur des sites non-libres, comme
https://www.facebook.com/groups/gnulilypond
https://music.stackexchange.com/
https://www.reddit.com/r/lilypond/

Je me demande ce que les gens qui vont sur Facebook par exemple lui trouvent de
mieux, étant donné (en plus de l'aspect « sangsue de la vie privée ») que ce
n'est vraiment pas pratique pour poster du code... Je ne sais pas vraiment si
c'est parce que ces personnes ont l'habitude de Facebook pour tout, ou si c'est
qu'elles préfèrent le style d'interface plutôt qu'une mailing list. Mais je ne
dis pas que Sympa serait forcément moins familier pour madame Michu, je n'en ai
pas d'expérience en réalité.

> J'ai des doutes sur Discourse:
> https://meta.discourse.org/t/email-support-with-discourse/168483

Attention, le lien que tu mentionnes parle d'une configuration assez
particulière, où l'utilisateur veut que les messages envoyés à l'adresse du
Discourse ne soient pas publics mais tombent dans un groupe privé. Ce n'est pas
le cas habituel.

Qu'est-ce que tu entends par « faire SMTP » ?

Cordialement,
Jean

---

From: Olivier Miakinen <[email-masked]>
Date: Thu, 29 Jun 2023 10:10:37 +0200

Le 29/06/2023 09:58, Jean Abou Samra a écrit :
> lists

Étant sensibilisé aux questions d'inclusion, et au fait de ne pas exclure
les personnes qui pourraient être rebutées par du courriel en mode texte
plutôt que des interfaces plus 'user friendly', je comprends parfaitement
cette préoccupation.

Cependant...

... s'agissant du logiciel LilyPond dans lequel la saisie se fait en mode
texte et pas avec une interface de type clickodrome, existe-t-il vraiment
des utilisateurs pouvant se sentir exclus si le forum d'entraide se fait
par courriels en mode texte ?

---

From: Bernard Choppy <[email-masked]>
Date: Thu, 29 Jun 2023 10:18:08 +0200

Bonjour à tous,

Le 29/06/2023 à 08:36, bernard.j.barbier a écrit :
> Car s'il s'appelle comme ça parce que c'est moi qui l'a nommé.

Bravo, alors, aussi bien pour le nom que pour le logiciel !

Ma position sera un poil différente de celle des autres : je pense que 
la clef de la pérennité est celle de l'hébergement. Il faut donc tenter 
de trouver un hébergeur (de préférence libre et gratuit) pour la liste 
et ses archives.

L'offre est loin d'être pléthorique et effectivement Framagroupes ne 
permet pas les archives.

Cela dit, est-il nécessaire d'avoir les deux fonctionnalités chez le 
même hébergeur ?

Je pense plus facile, le cas échéant, de faire migrer des archives (dont 
on aura choisi le système de consultation une bonne fois) d'un 
fournisseur à l'autre plutôt que la liste elle-même.

J'imagine, par exemple, un Wordpress posé chez Byet free avec 
l'extension RSS : le système d'article est efficace, je crois (mais je 
ne suis pas assez compétent pour le faire moi-même ;-).

Finalement, un système d'archivage, ça peut être simplement un des 
destinataires de la liste. Il suffit qu'il conserve tous les messages.

En plus, on peut imaginer sécuriser cela avec un gestionnaire de 
versions (Github ?) et du coup, on se prémunit des coups de Trafalgar et 
tout un chacun peut même disposer d'une archive complète en cas de besoin.

Pensez-vous réaliste de migrer la liste sur Framagroupes et de conserver 
les archives ailleurs ?

Bien à vous,

-- 

Bernard Choppy

---

From: Bernard Barbier <[email-masked]>
Date: Thu, 29 Jun 2023 10:36:13 +0200

Pas en 2.6.9, mais en 6.2.9. Désolé... dys dys dys...

Le 29/06/2023 à 10:30, Bernard Barbier a écrit :
>
>
> Bonjour,
>
> Réponse à Jean :
>
>>
>> Pour Sympa, je voulais tester, mais sur 
>> https://lists.sympa.community/compose_mail/en/html_news_letter , je 
>> lis « Posting from Web interface is closed for now ». Bernard, est-ce 
>> que vous savez si c'est temporaire ?
>
> Je ne pense pas... ici, en 2.6.9,  ça fonctionne toujours, mais, cela 
> fait quelques années que j'ai passé le relais de l'administration....
>
>
>>
>>

---

From: Bernard Barbier <[email-masked]>
Date: Thu, 29 Jun 2023 10:30:46 +0200

Bonjour,

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 10:40:58 +0200

Le jeudi 29 juin 2023 à 10:30 +0200, Bernard Barbier a écrit :
> > sur https://lists.sympa.community/compose_mail/en/html_news_letter , je lis
> > « Posting from Web interface is closed for now ». Bernard, est-ce que vous
> > savez si c'est temporaire ?
> >  
>  
> Je ne pense pas... ici, en 2.6.9,  ça fonctionne toujours, mais, cela fait
> quelques années que j'ai passé le relais de l'administration....

Pour ma part, dans deux navigateurs différents (Firefox et Chromium), j'obtiens
ceci en visitant la page https://lists.sympa.community/compose_mail/sandbox :

Le pied de page affiche « Powered by Sympa 6.2.72+ ».

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 10:48:33 +0200

> Oui, là je suis d'accord avec toi.

Sauf que les gestionnaires de ML disposent normalement dans la config 
du mode de réponse par défaut: à la liste ou à l'auteur.

Le choix est normalement chez l'admin. Ensuite chaque écrivain peut
choisir aussi de son côté de respecter le défaut ou pas.

Cordialement,
bruno.

---

From: Bernard Barbier <[email-masked]>
Date: Thu, 29 Jun 2023 10:49:07 +0200

Hello (re-)

snifff.... mais aussi, les bacs à sable, on a vite tendance à bloquer 
quelques facilités, j'en sais qqchose sur d'autres trucs (ie django : ).
Faut faire un TP !
Mais ça veut dire une VM, un serveur LAMP (au moins), un réglage subtil 
du SMTP... et du temps.

Les chicoufs (*) débarquant ,en milieu de semaine prochaine, je n'aurai 
pas le temps avant la rentrée...

Désolé.

BB.

(*) les chicoufs : se dit des petits enfants, chic, ils arrivent, ouf, 
ils repartent ! et avec 9, y a du volume !!!

Le 29/06/2023 à 10:40, Jean Abou Samra a écrit :
>>> lis « Posting from Web interface is closed for now ». Bernard, 
>>> est-ce que vous savez si c'est temporaire ?
>>
> Pour ma part, dans deux navigateurs différents (Firefox et Chromium), 
> j'obtiens ceci en visitant la page 
> https://lists.sympa.community/compose_mail/sandbox :
>
>
>

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 10:51:42 +0200

> Pensez-vous réaliste de migrer la liste sur Framagroupes et de conserver 

Pour Framagroupes, je ne pense pas car il y a quelques limitations décrites ici
:

https://framagroupes.org/abc/fr/

En particulier, « l'ajout en masse d'abonné⋅es est interdit », donc on ne
pourrait pas migrer la liste. De plus, la limitation à 500 abonnés serait un
gros problème si on venait plus tard à migrer la liste anglophone, qui est à
1800 abonnés.

Par contre, c'est vrai que c'est une option de ne pas migrer la liste mais de
lui donner simplement des archives plus convenables (ce qui ne résout pas tous
les problèmes, mais améliore quand même la situation). Maintenant que j'y pense,
on pourrait inscrire la liste sur https://mail-archive.com (apparemment, il y a
une possibilité d'importer les mbox des archives actuelles). Au moins, on aurait
une recherche avec Unicode !

Cordialement,
Jean

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 10:52:15 +0200

> Je reconnais que j’aime beaucoup la déduction fiscale ;-)

Mais pour que l'association l'ait, il faut travailler aussi:
https://www.associations.gouv.fr/une-liste-actualisee-des-associations-reconnues-d-utilite-publique.html
https://www.demarches.interieur.gouv.fr/particuliers/impot-revenu-dons-aux-associations-organismes-interet-general

et atteindre les bons critères. A-t-on 200 adhérents potentiels ?

Cordialement,
Bruno.

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 10:56:51 +0200

> choisir aussi de son côté de respecter le défaut ou pas.

En effet, on a le choix. Par contre, c'est fortement déconseillé par la
documentation de Mailman. Voici ce qui est écrit à propos du réglage dans
l'interface administrative :

reply_goes_to_list (general): Destination des réponses aux messages adressés à la liste ? Expéditeur est fortement recommandé pour la plupart des listes de diffusion.
Cette option contrôle ce que Mailman fait des en-têtes Reply-To: des messages
qui arrivent sur cette liste. Quand il a la valeur expéditeur, Mailman n'ajoute
pas d'en-tête Reply-To:, et s'il y en a un dans le message original, il n'est
pas supprimé. Mettre cette valeur à Cette liste ou a adresse explicite oblige
Mailman à insérer un en-tête Reply-To: spécifique à tous les messages, annulant
ainsi l'en-tête du message original si nécessaire (l'option adresse explicite
insère la valeur de reply_to_address). 

Il y a plusieurs raisons qui militent pour ne pas introduire ou ou remplacer
l'en-tête Reply-To:. Parmi ces raisons on peut citer le fait que beaucoup
d'expéditeurs dépendent de leurs Reply-to: pour réacheminer leurs messages. Une
autre raison est le fait que la modification du Reply-To: rend plus difficile
les réponses privées. Lire `Reply-To` Munging Considered Harmful pour une
discussion générale sur le problème. Lire Reply-To Munging Considered Useful
pour un panorama. 

Cordialement,
Jean

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 11:05:38 +0200

> l'interface administrative :

Et voici ce que fait Sympa dans sa conf:

I don't want replies to messages to go back to the whole list!

    By default Sympa will send replies back to the entire list. If you don't want that you need to change the "Reply address" section.

    The "value" pull down menu can be set to the following settings:

        All - Sends replies to the sender and the entire list. (default)
        List - Sends replies to the entire list.
        Sender - Sends replies to the address in the From: header.
        Other_email - Sends replies to the address entered in the "other email address" field. (below the pulldown menu)

    By setting the "respect of existing header field" to "forced" you can force your settings to override any settings that the sender set in the original message.

Juste pour info.

Mais le mieux est peut-être de garder mailman, d'y abonner une adresse
de service d'archivage libre et de les gérer comme cela si le reste va
bien (pourquoi changer ce qui marche ;-)

Bruno.

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 11:21:07 +0200

Rebonjour,

Le jeudi 29 juin 2023 à 10:49 +0200, Bernard Barbier a écrit :
>  
> Hello (re-)
>  
> snifff.... mais aussi, les bacs à sable, on a vite tendance à bloquer quelques
> facilités, j'en sais qqchose sur d'autres trucs (ie django : ). 
> Faut faire un TP !
> Mais ça veut dire une VM, un serveur LAMP (au moins), un réglage subtil du
> SMTP... et du temps.
>  
> Les chicoufs (*) débarquant ,en milieu de semaine prochaine, je n'aurai pas le
> temps avant la rentrée...
>  
> Désolé.
>  
> BB.
>  
> (*) les chicoufs : se dit des petits enfants, chic, ils arrivent, ouf, ils
> repartent ! et avec 9, y a du volume !!!

J'ai posé la question ici :

https://lists.sympa.community//arc/fr/2023-06/msg00024.html

Cordialement,
Jean

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 11:41:25 +0200

> mal à imaginer qu'on puisse l'éviter avec ce fonctionnement à deux adresses.

C'est une crainte justifiée, à laquelle je n'avais pas du tout pensé. Très bonne
remarque.

Je n'ai pas de vraie expérience de ce problème, car dans l'instance Discourse
que je suis activement en ce moment, il me semble que la plupart des gens
répondent par l'interface. En tous cas, la création de sujet par mail n'est pas
configurée.

Je pense que le problème serait résolu ou grandement diminué en personnalisant
un peu le bas du message, pour qu'au lieu de

Voir le sujet [bouton] ou répondre à cet e-mail pour répondre

on ait

Pour poster dans ce sujet, répondez à cet email, ou cliquez ici [bouton]
Pour créer un nouveau sujet, envoyez un emai à [email-masked] [lien mailto], ou
cliquez ici [bouton]

> suppose que c'est encore pire s'il y a deux niveaux de citation.

Là, je suis d'accord avec toi, c'est agaçant. Je vois qu'il y a une demande
récente de changer ça :

https://meta.discourse.org/t/format-quotes-in-plain-text-e-mail-correctly/262814

Je ne sais pas s'il y a un moyen de contourner ce formatage qui n'a pas de sens
en attendant.

(Personnellement, je lis les mails en HTML, mais je comprends qu'on puisse
préférer le texte simple.)

Cordialement,
Jean

---

From: Jean-Jacques Gerbaud <[email-masked]>
Date: Thu, 29 Jun 2023 12:05:53 +0200

> Bonjour à tous,
Bonjour Jean et bonjour aussi à tous ceux qui ont déjà répondu, (ou pas encore).
> Ce mail est inhabituellement long, veuillez m'en excuser.

Tous les mails de la liste sont lus (ou au moins les titres. J'avoue que je survole ceux traitant 
des percussions ! 😏 )

Pour répondre au message initial de Jean, j'ai eu le choix entre "répondre" et "répondre à la liste"
Facile de faire son choix et ne présente aucun problème. On peut évidemment se tromper mais les cas 
sont plutôt rares, à mon avis.

Le sujet mentionné par Jean m'a surpris et je trouve que la liste fonctionne bien mais les problèmes 
mis en avant m'étaient inconnus et doivent trouver une solution. Heureusement il n'y a pas urgence, si ?

Pour ma part, je préfère, comme certains autres qui ont déjà répondu, un logiciel libre. Mais, je ne 
suis pas un cador de l'informatique et je redoute un peu les manips qu'il faudra obligatoirement 
faire et que je ferai, bien sûr. Je vous fais confiance pour nous aider dans notre migration.

Je suis aussi favorable à une cotisation (annuelle) si c'est nécessaire.

> Cordialement,

Merci Jean de t'occuper de nous.

-- 
JJG

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 12:11:22 +0200

Le jeudi 29 juin 2023 à 11:05 +0200, Bruno Cornec a écrit :
>     By default Sympa will send replies back to the entire list. If you don't
> want that you need to change the "Reply address" section.
> 
>         Other_email - Sends replies to the address entered in the "other email
> address" field. (below the pulldown menu)
> 
> 
>     By setting the "respect of existing header field" to "forced" you can
> force your settings to override any settings that the sender set in the
> original message.
> 
> Juste pour info.

D'accord, donc c'est la religion opposée. Je vois :-)

(Il serait bon de garder le réglage cohérent entre cette liste et les listes
anglophones, pour ne pas surprendre ceux qui sont abonnés des deux côtés, donc
il faudrait un peu de concertation avant de le changer, mais on peut
l'envisager.)

> bien (pourquoi changer ce qui marche ;-)

Comme j'essayais de l'expliquer dans mon message initial, ce qui marche
aujourd'hui ne marche malheureusement pas si bien : délais d'envoi, mails perdus
inexplicablement, comptes résiliés qui continuent à recevoir des mails (je l'ai
vu aussi), administrateurs très peu disponibles, Mailman 2, etc.

Pour la petite histoire, le jour où j'ai demandé à être nommé admin des listes
anglophones, qui n'avaient plus d'admin actif, il a fallu trois mois entre la
demande et l'autorisation. Les administrateurs du serveur font ce qu'ils peuvent
avec leurs disponibilités, je suis simplement un peu refroidi par le manque
apparent de personnes à ce niveau-là. Le serveur fonctionne pour les opérations
courantes, mais il y a quand même des fragilités techniques importantes.

Cordialement,
Jean

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 12:25:53 +0200

> sont plutôt rares, à mon avis.

Normalement, si la réponse est privée par accident, tu ne la vois pas, sauf si
elle t'est adressée :-)

(J'ai un filtre mail pour tous les mails privés envoyés par des personnes liées
à LilyPond, qui comporte actuellement plus de 240 adresses :-)

Cela dit, ce n'est pas bien grave et pas du tout le problème principal à mon
sens.

(Autre problème connexe : les personnes qui ont plusieurs adresses peuvent se
tromper d'adresse, ce qui fait passer le message en modération. Cela arrive
assez régulièrement. Mais là aussi, je ne considère pas que cela soit un gros
problème.)

> il n'y a pas urgence, si ?

Non, il n'y a absolument pas d'urgence.

> Pour ma part, je préfère, comme certains autres qui ont déjà répondu, un
> logiciel libre.

Moi aussi. De toute façon, ce n'est pas bien compliqué, LilyPond est un projet
GNU donc on ne peut pas, vis-à-vis de GNU, se mettre sur un hébergement non-
libre.

> Mais, je ne suis pas un cador de l'informatique et je redoute un peu les
> manips qu'il faudra obligatoirement 

Quel que soit le nouveau système (Sympa, Mailman 3, Discourse), je m'attends à
ce que la migration soit facile pour les utilisateurs existants, mais je n'ai
pas encore exploré tous les détails (je voulais justement en discuter un peu
avant d'y passer beaucoup de temps).

> Je suis aussi favorable à une cotisation (annuelle) si c'est nécessaire.

Je pense qu'il vaut mieux ne pas demander à tous les abonnés de cotisation (est-
ce ce que tu suggérais), pour ne pas mettre de barrière à l'inscription.

Par contre, en se cotisant *volontairement*, on devrait pouvoir atteindre les
coûts du serveur pour un prix modique par personne si suffisamment de personnes
sont volontaires.

Cordialement,
Jean

---

From: Raphael HARDY <[email-masked]>
Date: Thu, 29 Jun 2023 12:47:10 +0200

Hello, j'ajoute ma pierre: moi aussi je survole souvent cette mailing list, mais sans beaucoup intervenir. Je suis pour la migration vers Discourse ou un système semblable pour toutes les raisons qui ont été données. Je pense que je m'investirais davantage sur un Discourse que sur une mailing list et je ne suis peut-être pas le seul dans ce cas. Je trouve notamment plus facile de rejoindre une communauté dans un espace séparé en catégories et en sujets qu'une mailing list où les messages fusent, parfois opaque pour les gens qui débarquent.
Je serai aussi prêt à participer pour financer les frais de fonctionnement 👍
Raphael

> On 29 Jun 2023, at 12:25, Jean Abou Samra <[email-masked]> wrote:
> 
> Normalement, si la réponse est privée par accident, tu ne la vois pas, sauf si elle t'est adressée :-)
> 
> (J'ai un filtre mail pour tous les mails privés envoyés par des personnes liées à LilyPond, qui comporte actuellement plus de 240 adresses :-)
> 
> Cela dit, ce n'est pas bien grave et pas du tout le problème principal à mon sens.
> 
> (Autre problème connexe : les personnes qui ont plusieurs adresses peuvent se tromper d'adresse, ce qui fait passer le message en modération. Cela arrive assez régulièrement. Mais là aussi, je ne considère pas que cela soit un gros problème.)
> 
> 
>> Pour ma part, je préfère, comme certains autres qui ont déjà répondu, un logiciel libre.
> 
> 
> Moi aussi. De toute façon, ce n'est pas bien compliqué, LilyPond est un projet GNU donc on ne peut pas, vis-à-vis de GNU, se mettre sur un hébergement non-libre.
> 
> 
>> Mais, je ne suis pas un cador de l'informatique et je redoute un peu les manips qu'il faudra obligatoirement 
> Quel que soit le nouveau système (Sympa, Mailman 3, Discourse), je m'attends à ce que la migration soit facile pour les utilisateurs existants, mais je n'ai pas encore exploré tous les détails (je voulais justement en discuter un peu avant d'y passer beaucoup de temps).
> 
> 
> Je pense qu'il vaut mieux ne pas demander à tous les abonnés de cotisation (est-ce ce que tu suggérais), pour ne pas mettre de barrière à l'inscription.
> 
> Par contre, en se cotisant *volontairement*, on devrait pouvoir atteindre les coûts du serveur pour un prix modique par personne si suffisamment de personnes sont volontaires.
> 
> Cordialement,
> Jean
>

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 12:54:12 +0200

> par courriels en mode texte ?

Pour moi, le problème qui peut se poser n'est pas forcément que les utilisateurs
soient rebutés par les courriels ou se sentent exclus, mais plutôt qu'ils aient
du mal à comprendre le système.

Par exemple, suite à la fermeture de Nabble, j'ai aidé en privé quelques
personnes qui ne comprenaient pas comment poster sur la liste, dont une qui
pourtant recevait les messages de la liste. Exemple plus personnel : la première
fois que j'ai posté moi-même sur la liste, c'était pour signaler un bug, et j'ai
beaucoup hésité avant de le faire, étant très intimidé (je n'avais jamais posté
sur une mailing list auparavant et j'avais peur de mal faire ; j'avais 15 ans à
l'époque).

Ceci étant, je ne dis pas que Discourse n'a que du bon non plus.

Amicalement,
Jean

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 12:55:23 +0200

> Je me demande ce que les gens qui vont sur Facebook par exemple lui trouvent de

D'une manière générale, je me demande la même chose ;-)
Mais tu as raison, sans doute l'habitude, et le fait qu'on y trouve 1/5è
de la population mondiale aussi je pense. Ce qui n'est pas notre souci
non plus.

> Qu'est-ce que tu entends par « faire SMTP » ?

Je ne sais pas comment Discourse fonctionne par derrière, mais à un
moment donné, il faut envoyer un mail. Ceci ne peut se faire qu'en
utilisant le protocole SMTP. Et donc avoir qq part un
postfix/sendmail/... configuré correctement pour le faire bien, sans
être vu comme un spammeur, et aujourd'hui en ayant DKIM/DMAC/SPF de
configuré pour aider à cela.

Bruno.

---

From: Jean Abou Samra <[email-masked]>
Date: Thu, 29 Jun 2023 13:01:50 +0200

> configuré pour aider à cela.

Oui, c'est sûr. Ce n'est pas différent de ce qu'il faudrait configurer pour un
serveur de mailing list, non ?

Cordialement,
Jean

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 13:07:07 +0200

> serveur de mailing list, non ?

Non, pas nécessairement. Le front-end Web (fourni pas Discourse, Sympa
ou mailman) est disjoint du backend mail qu'il faut configurer et dont
tous ont besoin.

Bruno.

---

From: Bruno Cornec <[email-masked]>
Date: Thu, 29 Jun 2023 13:04:33 +0200

> vu aussi), administrateurs très peu disponibles, Mailman 2, etc.

Exact. Mais ces aspects là ne sont-ils pas des problèmes côté SMTP plus
que mailman ?

Si le serveur a une mauvaise réputation, il se peut que des msgs soient
blacklistés par ex. Les délais peuvent venir de la mutualisation avec
des listes à fort traffic qui monopolisent le serveur de mail, la
gestion des archives, ...

> courantes, mais il y a quand même des fragilités techniques importantes.

Hélas, à part de nouveaux entrants comme toi (merci !) je monde du libre
souffre globalement de manque de ressources (humaines, financières,
moyens infos, ...) Malheureusement on a déjà vu que pas mal de projets
ne reposent en réalité que sur la bonne volonté de quelques individus
qui doivent aussi boire, manger, dormir, travailler, ... et j'en passe
:-)

Le fait que tu soulèves ce point, et les réponses qui se font jour
depuis montrent qu'il y a peut-être moyen de mutualiser nos efforts au
sein d'une petite équipe de sysadmin gérant une infra en propre pour
lilypond (y compris les ML WW) pour faire un retour à la communauté. Si
tu as 3 personnes prêtes à le faire, et échangeant bien les infos, cela
devrait permettre de gérer correctement la chose. 

Dans notre association FLOSSITA, (pas très active cette année), on avait
réfléchi avec René Ribaud (en Cc:) à mettre à disposition ce genre de
service pour la communauté. Nous utilisons un serveur hébergé déjà, il
"suffirait" de mettre un Sympa/mailman3 en docker sur notre machine et
le reste peut rouler. René qu'en penses-tu ? Il ne serait pas ouvert à
tout le monde, mais on doit pouvoir héberger quelques ML choisies et
assurer l'admin (avec des backupus répliqués pour être tranquilles en
cas de pb et de l'ansible pour le setup).

En tout cas, moi, c'est le genre de projet sur lequel j'aime travailler,
donc il ne faudra pas me pousser beaucoup ;-)

Cordialement,
Bruno.

---

From: Olivier Miakinen <[email-masked]>
Date: Thu, 29 Jun 2023 23:55:24 +0200

> par courriels en mode texte ?

Bernard Meylan vient de répondre à ma question d'une manière très
convaincante. Merci à toi, Bernard, et je n'ai pas d'autre question
ni objection : je suis maintenant convaincu qu'il est utile de garder
la possibilité d'accéder à la liste sur le web et sans courrielleur.

Cordialement,
-- 
Olivier Miakinen

---

From: Martial R <[email-masked]>
Date: Fri, 30 Jun 2023 08:15:11 +0200

Bonjour à tous

Je ne sais quoi répondre n'étant pas compétent en matière de forum, flux
RSS, etc.
Je lis tous les messages sur l'interface de google mail .
J'utilise régulièrement les archives pour trouver une réponse à un
problème, ce n'est pas simple pour s'y retrouver.
et les publications arrivent/partent souvent dans le désordre.
Tout ce qui simplifiera la lecture et l'envoi de messages
réponses/questions sans passer par un courrielleur me satisfera.

Bonne journée.
Martial Rameaux

---

From: <[email-masked]>
Date: Fri, 30 Jun 2023 09:09:48 +0200

Je suis un fervent utilisateur du mail des questions et réponses de la liste du forum. Je lis tout et parfois teste et garde certains aspects dans mes outils. Je suis dépassé par toutes les nouvelles technologies et donc me contente d'Outlook, Windows 10 et Frescobaldi-Lilypond. L'avantage du mail : on peut trier par date, émetteur, récepteur sujet etc..
Ce serait plus facile si on pouvait accéder à l'historique complet sur base de questions mots-clés etc. comme dans les mails par exemple.   
Daniel Bernair 

-----Message d'origine-----
De : lilypond-user-fr-bounces+daniel.bernair=[email-masked] <lilypond-user-fr-bounces+daniel.bernair=[email-masked]> De la part de Jean Abou Samra
Envoyé : mercredi 28 juin 2023 21:33
À : lilypond-user-fr <[email-masked]>
Objet : Réflexion sur l'infrastructure de la liste

Bonjour à tous,

J'aimerais ouvrir une discussion sur un sujet qui me paraît important, à savoir l'infrastructure qui nous permet, communauté francophone de LilyPond, d'être en contact et de nous entraider.

Depuis le départ, les interactions se sont faites sur cette liste de diffusion, lilypond-user-fr, dont Valentin Villenave a toujours été l'administrateur, rejoint par moi il y a quelques années. LilyPond étant un logiciel rattaché au projet GNU, il était très naturel d'utiliser une liste de diffusion par emails, comme la plupart des autres projets GNU, et également comme la partie anglophone de la communauté LilyPond (avec les listes lilypond-user, équivalent anglophone de cette liste, ainsi que lilypond-devel, la liste des développeurs, et bug-lilypond, la liste des rapports de bug ; par contre la communauté germanophone a un forum Simple Machines, https://lilypondforum.de).

Jusqu'à il y a quelques années, il était également possible de lire et poster sur la liste à travers le portail Nabble plutôt que de recevoir les mails, ce qui était jugé plus pratique par certains. Malheureusement, Nabble a mis la clé sous la porte en 2021 (voir https://lists.gnu.org/archive/html/lilypond-user-fr/2021-06/msg00133.html,
https://lists.gnu.org/archive/html/lilypond-user-fr/2021-07/msg00000.html,
https://lists.gnu.org/archive/html/lilypond-user-fr/2021-07/msg00064.html).
Suite à cela, j'ai cru comprendre qu'un certain nombre de personnes étaient un peu déçues de devoir passer par les mails. J'ai essayé de trouver une alternative à Nabble, sans succès. À l'époque, je n'ai trouvé qu'un logiciel de forum (FUDforum) qui aurait pu être une interface à une liste de diffusion existante, et il y avait des problèmes techniques. Les autres nécessitaient de déménager la liste entièrement.

Aujourd'hui, je me demande justement si un déménagement serait souhaitable. D'un côté, je suis relativement attaché à l'infrastructure des listes de diffusion GNU, notamment parce qu'elle est sur pied sans interruption depuis plus longtemps que LilyPond n'existe (plus de 20 ans), sans nécessiter aucune maintenance de notre part, alors que dans le même temps, un certain nombre de sites liés à LilyPond (je pense par exemple à lilynet.net, où il y avait autrefois une liste de diffusion pour les traducteurs, ou encore lilybin.com ou
lilypondblog.org) ont fermé parce que leurs créateurs ou mainteneurs n'étaient plus disponibles, comme il arrive à chacun. D'un autre côté, je dois reconnaître que l'hébergement actuel comporte quelques inconvénients notables.

Cela étant dit, les questions sur une éventuelle migration sont multiples. Les plus immédiates sont : vers quel système ? Et comment organiser la migration, pour éviter le pire qui serait de perdre une partie de la communauté en route ?

Il y a de nombreux logiciels de forum de discussion. Je crois que le plus répandu à l'heure actuelle pour les logiciels libres est Discourse ; en tous cas, c'est le seul dont j'aie vraiment une expérience à part les listes de diffusion, car il est utilisé dans d'autres communautés liées aux logiciels libres que je suis de près ou de loin, notamment la communauté Python anglophone
(https://discuss.python.org) et francophone (https://discuss.afpy.org) ainsi que le projet GNOME (https://discourse.gnome.org) ou encore le langage Rust (https://users.rust-lang.org, https://internals.rust-lang.org). Il y a du bon et du mauvais dans Discourse, je n'en suis pas fan inconditionnel (je pense au système de « likes » qui ressemble un peu trop aux réseaux sociaux à mon goût, même si c'est parfois utile), mais cela marche globalement plutôt bien à mon sens. De plus, contrairement à certaines alternatives comme Google Groups, c'est un logiciel libre. L'idée serait d'avoir un serveur Discourse auto-hébergé. (Il faudra que deux ou trois personnes soient administratrices du serveur, pour que ce ne soit pas une catastrophe si l'une n'est plus disponible. https://fr.wikipedia.org/wiki/Facteur_d%27autobus )

Un point fort de Discourse est qu'il reste possible d'interagir avec la liste exclusivement par mails, en s'abonnant aux notifications et en y répondant (il y a aussi une adresse spéciale pour créer un nouveau sujet). Dans un sens, cela correspond au logiciel idéal que je cherchais il y a deux ans pour remplacer Nabble, sauf qu'on ne peut pas garder l'adresse actuelle de la liste avec Discourse.

Dans l'hypothèse d'une migration, il faudrait que les archives existantes soient transférées vers le nouveau système. C'est la partie la plus compliquée, le reste étant a priori plus simple.

Il devrait aussi être possible de configurer le nouveau serveur pour que tous les abonnés actuels aient un compte créé automatiquement et reçoivent les notifications, de sorte à avoir une continuité.

On pourrait aussi demander des conseils dans d'autres communautés qui ont opéré une migration similaire, comme Python et GNOME.

Soyons très clairs : même si je suis administrateur (avec Valentin, que je n'ai toutefois pas vu depuis un moment), il est hors de question que je prenne une décision dans mon coin et que je l'applique. Si migration il y a, elle sera décidée collectivement. En règle générale, dans les projets de logiciel libre, la méthode de décision par consensus fonctionne très bien (discuter et voir si un consensus émerge, ce qui est souvent le cas).

On ne va pas chercher à prendre une décision finale avant d'avoir fait des tests sérieux, mais comme il y a malgré tout un certain nombre de détails à comprendre, j'aimerais d'abord avoir une idée du sentiment général vis-à-vis d'une migration éventuelle. Je veux juste éviter de passer plusieurs jours cet été le nez dans le cambouis de Discourse pour me rendre compte a posteriori que personne n'en veut.

Un dernier point. Bien sûr, tout ceci s'applique aussi à la liste anglophone. Simplement, la migrer est encore une affaire d'un autre ordre (elle a beaucoup plus d'abonnés), donc je pense qu'il est sage que la communauté francophone fasse d'abord son choix indépendant. Si nous migrons, avec le recul sur cette expérience, migrer les autres listes deviendra plus raisonnable et pourrait se faire après discussion sur ces listes.

N'hésitez pas à poser des questions et exprimer votre avis. Si vous voulez vous faire une idée de l'interface de Discourse, vous pouvez allez fouiner sur https://discuss.afpy.org (l'instance de l'Association Francophone Python).

Cordialement,
Jean

---

From: Sebastien Richard <[email-masked]>
Date: Fri, 30 Jun 2023 08:27:31 +0000

Bonjour à tous,

Je suis loin de tout comprendre sur les problèmes techniques, cependant pour ma part, avoir un accès simplifié aux archives serait un plus  non négligeable. Une interface web pour interagir les uns avec les autres, pourquoi pas même si la liste de diffusion me convient également.

S'il faut soutenir la communauté financièrement, je réponds présent (je ne suis pas crésus mais ça me parait normal de contribuer).

@+,

-----------
 Sébastien

________________________________
From: lilypond-user-fr-bounces+richardsgjm=[email-masked] <lilypond-user-fr-bounces+richardsgjm=[email-masked]> on behalf of daniel.bernair--- via Liste de diffusion francophone autour de LilyPond <[email-masked]>
Sent: Friday, June 30, 2023 09:09
To: 'Jean Abou Samra' <[email-masked]>; 'lilypond-user-fr' <[email-masked]>
Subject: RE: Réflexion sur l'infrastructure de la liste

-----Message d'origine-----
De : lilypond-user-fr-bounces+daniel.bernair=[email-masked] <lilypond-user-fr-bounces+daniel.bernair=[email-masked]> De la part de Jean Abou Samra
Envoyé : mercredi 28 juin 2023 21:33
À : lilypond-user-fr <[email-masked]>
Objet : Réflexion sur l'infrastructure de la liste

Bonjour à tous,

Depuis le départ, les interactions se sont faites sur cette liste de diffusion, lilypond-user-fr, dont Valentin Villenave a toujours été l'administrateur, rejoint par moi il y a quelques années. LilyPond étant un logiciel rattaché au projet GNU, il était très naturel d'utiliser une liste de diffusion par emails, comme la plupart des autres projets GNU, et également comme la partie anglophone de la communauté LilyPond (avec les listes lilypond-user, équivalent anglophone de cette liste, ainsi que lilypond-devel, la liste des développeurs, et bug-lilypond, la liste des rapports de bug ; par contre la communauté germanophone a un forum Simple Machines, [https://lilypondforum.de)]https://lilypondforum.de).

Il y a de nombreux logiciels de forum de discussion. Je crois que le plus répandu à l'heure actuelle pour les logiciels libres est Discourse ; en tous cas, c'est le seul dont j'aie vraiment une expérience à part les listes de diffusion, car il est utilisé dans d'autres communautés liées aux logiciels libres que je suis de près ou de loin, notamment la communauté Python anglophone
(https://discuss.python.org) et francophone (https://discuss.afpy.org) ainsi que le projet GNOME (https://discourse.gnome.org) ou encore le langage Rust (https://users.rust-lang.org, [https://internals.rust-lang.org)]https://internals.rust-lang.org). Il y a du bon et du mauvais dans Discourse, je n'en suis pas fan inconditionnel (je pense au système de « likes » qui ressemble un peu trop aux réseaux sociaux à mon goût, même si c'est parfois utile), mais cela marche globalement plutôt bien à mon sens. De plus, contrairement à certaines alternatives comme Google Groups, c'est un logiciel libre. L'idée serait d'avoir un serveur Discourse auto-hébergé. (Il faudra que deux ou trois personnes soient administratrices du serveur, pour que ce ne soit pas une catastrophe si l'une n'est plus disponible. https://fr.wikipedia.org/wiki/Facteur_d%27autobus )

Cordialement,
Jean

---

From: Jacques Menu <[email-masked]>
Date: Fri, 30 Jun 2023 13:56:06 +0200

Bonjour tutti,

Je n’ai pas de préférence quant à la manière d’utiliser la liste et les archives, et participerai volontiers au financement d’une nouvelle infrastructure si nécessaire.

Bon w-e!

JM

---

From: Martial R <[email-masked]>
Date: Fri, 30 Jun 2023 18:01:19 +0200

ha oui évidemment je participerai au financement si besoin !

-- 
Martial Rameaux

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 30 Jun 2023 18:19:20 +0200

> Le 29 juin 2023 à 10:52, Bruno Cornec <[email-masked]> a écrit :
> 

Je veux bien comprendre le chiffre de 200 … je ne l’ai lu nulle part. Je n’ai pas vu de minima d’adhérent pour les associations d'intérêt général. 

En revanche d’après le site web :
Quels sont les dons permettant d'obtenir une réduction d'impôt ?
Votre don doit être fait à un organisme qui remplit les 3 conditions suivantes :
    Il est à but non lucratif
    Il a un objet social et une gestion désintéressée
    Il ne fonctionne pas au profit d'un cercle restreint de personnes.

Une association d’entraide et d’éducation populaire autour des logiciels libres en général et de LilyPond en particulier permettrait la déduction fiscale !

Je ne sais pas si helloasso, https://www.helloasso.com <https://www.helloasso.com/>, est très libre, mais cette plateforme fonctionne plutôt bien et délivre les reçus fiscaux à l’aide d’une simple croix à cocher ! Donc pas de gestion administrative !

Au vu du nombre de personnes qui se proposent de contribuer, le serveur est payé, au mois pour la première année !

À bientôt,
Philippe

---

From: Bruno Cornec <[email-masked]>
Date: Fri, 30 Jun 2023 23:42:37 +0200

> Je veux bien comprendre le chiffre de 200 … je ne l’ai lu nulle part. Je n’ai pas vu de minima d’adhérent pour les associations d'intérêt général. 

Premier lien:
"l’association doit en outre avoir au moins trois ans de pratique comme association déclarée, compter au moins 200 membres"

> Une association d’entraide et d’éducation populaire autour des logiciels libres en général et de LilyPond en particulier permettrait la déduction fiscale !

Une fois les conditions réunies. 

> Je ne sais pas si helloasso, https://www.helloasso.com <https://www.helloasso.com/>, est très libre, mais cette plateforme fonctionne plutôt bien et délivre les reçus fiscaux à l’aide d’une simple…

Une fois les conditions réunies.

Bruno.