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

[Jean Abou Samra]

Le mercredi 28 juin 2023 à 22:32 +0200, Olivier Miakinen a écrit :

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.

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 ?

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.

Merci à toi !

Cordialement,

Jean

--- Begin Message --- Subject: [Py] [Core Development] Formalize the concept of "soft deprecation" (don't schedule removal) in PEP 387 "Backwards Compatibility Policy" Date: Fri, 16 Jun 2023 11:34:29 +0000

Paul Moore pf_moore CPython core developer June 16

Jean Abou Samra:

I like the concept of “soft deprecating”, but please don’t use PendingDeprecationWarning for it.

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 or reply to this email to respond.

To unsubscribe from these emails, click here.

                                                           

--- End Message ---

signature.asc
Description: This is a digitally signed message part