cc @tilgovi @berkerpeksag

Je voudrais obtenir les PRs suivants fusionnés pour 19.8 :

• [x] #1499 (je peux répondre à mes propres commentaires si nous décidons de fusionner celui-ci) (fermé comme non corrigé)
• [x] #1569 (va fusionner ce soir)
• [x] #1632 (révisé)

@berkerpeksag j'ai commenté/approuvé alors. Faites-moi savoir si vous avez besoin d'aide car j'aurai peut-être des cycles demain :)

J'ai des PR ouverts. Voulons-nous fusionner l'un d'entre eux ?

• [x] #1481 (autoriser les fichiers de configuration Python à définir chdir)
• [x] #1602 (je peux répondre aux commentaires de @berkerpeksag)

Les deux PR sont bons à avoir si nous avons le temps de les faire entrer.

Les miens sont là. Puis-je aider à réviser quoi que ce soit ?

1499 est le seul restant. J'ai répondu à mes commentaires.

@berkerpeksag j'ai commenté aussi, qu'en pensez-vous ?

@berkerpeksag je n'ai pas eu de réponse à propos de #1499 . Je doute de remettre en place une nature qui a été supprimée il y a longtemps. Nous devrions voir les avantages/inconvénients à ce sujet. Ou du moins en s'assurant que cela n'a pas d'impact.

Je pense cependant qu'avant de relâcher je désactiverai par défaut l'option SO_REUSEPORT du socket. Les pensées?

@benoitc Je ne suis pas sûr de comprendre - pourquoi voudrions-nous changer la valeur par défaut pour SO_REUSEPORT fonction de ce PR ?

(Nous comptons sur SO_RESUSEPORT pour nous aider à traiter efficacement des dizaines de milliers de requêtes/seconde, donc je fais attention aux modifications qui y sont apportées.)

Avoir SO_REUSEPORT par défaut semble dérouter certaines personnes, en particulier celles qui découvrent Gunicorn ou qui l'utilisent dans un environnement de développement. Il permet de démarrer un nouveau Gunicorn sans tuer l'ancien, ce qui entraîne l'exécution de plusieurs versions d'une application. Ce n'est pas une expérience très conviviale pour un utilisateur novice qui se demande pourquoi son application ne sert la bonne réponse que la moitié du temps.

Nous ne supprimerons certainement pas la fonctionnalité même si nous modifions la valeur par défaut.

@berkerpeksag je n'ai pas eu de réponse à propos de #1499 . Je doute de remettre en place une nature qui a été supprimée il y a longtemps. Nous devrions voir les avantages/inconvénients à ce sujet. Ou du moins en s'assurant que cela n'a pas d'impact.

En regardant à nouveau #1499, je suis d'accord pour le fermer comme « wontfix ». Le rendre compatible avec Gunicorn 19.4+ est assez trivial :

-            '-c', 'airflow.www.gunicorn_config'
+            '-c', 'python:airflow.www.gunicorn_config'

sur ma liste de choses à faire avant toute sortie, j'ai ce qui suit :

• [x] #1669 (ne pas activer l'utilisation de SO_REUSEPORT par défaut)
• [ ] #1653

je vais essayer d'avoir quelque chose pour vendredi maintenant

Y a-t-il d'autres nouvelles à ce sujet?

Je viens de fusionner le PR #1669 et de fermer le PR #1499 donc je pense que le seul bloqueur est maintenant #1653.

Je pense que nous devons également documenter le changement de comportement SO_REUSEPORT (PR #1669) dans les notes de version.

Wow, merci pour la réponse rapide. ??

Sachant que demander à l'ETA est le plus grand péché de tous, y a-t-il des nouvelles sur l'avancement du #1653 qui semblent bloquer la sortie ?

@benoitc @tilgovi devrions-nous laisser #1653 à 19.9 et publier 19.8 tel quel ? Il y a quelques correctifs importants dans master et il y a des questions d'utilisateurs sur ETA pour 19.8 dans plusieurs numéros (par exemple, #1058) donc je me demande si nous devrions sauter #1653 pour l'instant.

Il y a un PR presque prêt pour le #1324 :

• [ ] RP #1696

Je vais bien sauter #1653

Je ne vois aucune raison de ne pas sortir plus souvent :) Si je n'arrive pas avec un patch d'ici aujourd'hui, sortons demain matin.

À propos de ce truc pyc, je serais pour le corriger dans la version actuelle et ne pas ajouter de nouvelle option. Je préférerais déprécier cette fonctionnalité car elle rompt le contrat de rechargement automatique de la configuration et de telles choses.

Pypi semble être toujours en 19.7.1 https://pypi.python.org/pypi/gunicorn
En parallèle, le README.md pourrait-il avoir un numéro de version stable ?
passer par pypi pour vérifier quelle est la version actuelle me semble un peu génial, ou peut-être qu'il me manque un numéro de version évident affiché quelque part 😕

Désolé de bump, des nouvelles de la sortie 19.8 ? J'ai hâte de jouer avec dictConfig :-)

( @Allu2 Veuillez voir PR https://github.com/benoitc/gunicorn/pull/1727 pour afficher le numéro de version de la version actuelle dans le README)

Une mise à jour pour ceci? Je l'attends avec impatience car cela résout certains problèmes avec les --reload dans les conteneurs alpins et rendrait nos environnements de développement beaucoup plus agréables !

Je vais préparer une sortie. @berkerpeksag @benoitc c'est bien pour toi ?

@tilgovi +1 de moi.

Par curiosité, quel genre de processus consiste à créer une version gunicorn ?
Cette sortie semble avoir été reportée des 5 derniers mois avec plus d'un "prochain (jour | semaine | bientôt)"

@Allu2

• Mettre à jour le journal des modifications
• Marquer et télécharger
• Faire la sortie sur GitHub

Ce n'est pas difficile, mais nous le faisons tous bénévolement.

J'ai mis à jour le changelog et je pense que tout est prêt pour la publication.

Je vais dormir et couperai l'étiquette le matin, quand je pourrai être là en cas d'erreur nécessitant la publication d'un correctif de suivi, mais je ne m'attends à aucun problème.

19.8.0 est sorti !

S'il vous plaît commenter ici avec des commentaires ou des problèmes!

Nous allons viser des versions plus fréquentes à l'avenir. Vos demandes de tirage et vos avis vous aident. Si vous êtes intéressé à être un mainteneur, faites le moi savoir !

@tilgovi merci ! et d'accord :) désolé de ne pas avoir répondu bientôt j'ai voyagé tout le mois