Копия @tilgovi @berkerpeksag

Я хотел бы объединить следующие PR для 19.8:

• [x] # 1499 (я могу обратиться к своим комментариям, если мы решим объединить этот) (закрыто как wontfix)
• [x] # 1569 (объединим это сегодня вечером)
• [x] # 1632 (рассмотрено)

@berkerpeksag Я тогда прокомментировал / одобрил. Дайте мне знать, если вам понадобится помощь, потому что завтра у меня могут быть несколько циклов :)

У меня есть открытые PR. Мы хотим объединить кого-нибудь из них?

• [x] # 1481 (разрешить конфигурационным файлам Python устанавливать chdir)
• [x] # 1602 (я могу ответить на комментарии от @berkerpeksag)

Хорошо иметь оба PR, если у нас есть время, чтобы их ввести.

Мои присутствуют. Могу я помочь с обзором чего-нибудь?

1499 - единственный оставшийся. Я рассмотрел свои комментарии к обзору.

@berkerpeksag, я тоже прокомментировал, что ты об этом думаешь?

@berkerpeksag я не получил ответа по поводу № 1499. Я сомневаюсь в том, чтобы вернуть элемент, который был удален давным-давно. Мы должны увидеть все за / против. Или, по крайней мере, чтобы убедиться, что это не повлияет.

Однако я думаю, что перед выпуском я отключу по умолчанию параметр сокета SO_REUSEPORT. Мысли?

@benoitc Я не уверен, что понимаю - зачем нам менять значение по умолчанию для SO_REUSEPORT на основе этого PR?

(Мы действительно полагаемся на SO_RESUSEPORT чтобы помочь нам эффективно обслуживать десятки тысяч запросов в секунду, поэтому я осторожно отношусь к его изменениям.)

Использование SO_REUSEPORT по умолчанию, кажется, сбивает с толку некоторых людей, особенно тех, кто плохо знаком с Gunicorn или использует его в среде разработки. Это позволяет запустить новый Gunicorn, не убивая старый, что приводит к запуску нескольких версий приложения. Это не очень дружелюбный опыт для первого пользователя, который задается вопросом, почему его приложение дает правильный ответ только половину времени.

Мы точно не удалим эту функциональность, даже если изменим значение по умолчанию.

@berkerpeksag я не получил ответа по поводу № 1499. Я сомневаюсь в том, чтобы вернуть элемент, который был удален давным-давно. Мы должны увидеть все за / против. Или, по крайней мере, чтобы убедиться, что это не повлияет.

Снова посмотрев на # 1499, я могу закрыть его как «wontfix». Сделать его совместимым с Gunicorn 19.4+ довольно просто:

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

в моем списке дел перед любым выпуском у меня есть следующее:

• [x] # 1669 (не включать использование SO_REUSEPORT по умолчанию)
• [] # 1653

я постараюсь есть что-нибудь на пятницу сейчас

Есть еще какие-нибудь новости по этому поводу?

Я только что объединил PR # 1669 и закрыл PR # 1499, поэтому я думаю, что теперь единственный блокирующий номер # 1653.

Я думаю, нам также необходимо задокументировать изменение поведения SO_REUSEPORT (PR # 1669) в примечаниях к выпуску.

Вау, спасибо за быстрый ответ. 💯

Знание о том, что спрашивать ETA - величайший грех из всех, есть ли какие-либо новости о прогрессе # 1653, которые, кажется, не позволяют выпуску?

@benoitc @tilgovi должны ли мы оставить # 1653 на 19.9 и выпустить 19.8 как есть? В master внесены некоторые важные исправления, и есть несколько вопросов от пользователей по ETA для 19.8 в нескольких выпусках (например, # 1058), поэтому мне интересно, следует ли нам пока пропустить # 1653.

Практически готов PR для №1324:

• [] PR №1696

Я могу пропустить # 1653

Я не вижу причин не выпускать чаще :) Если я не пришел с патчем к сегодняшнему дню, давайте выпустим его завтра утром.

Что касается этого материала pyc, я бы исправил его в текущем выпуске и не добавлял никаких новых опций. Я бы предпочел отказаться от этой функции, поскольку она нарушает договор об автоматической перезагрузке конфигурации и тому подобное.

Pypi, похоже, все еще на уровне 19.7.1 https://pypi.python.org/pypi/gunicorn
В качестве побочной мысли можно ли сделать README.md стабильным номером версии?
прохождение через pypi, чтобы проверить, какая текущая версия кажется немного странной, или, возможно, мне не хватает какого-то очевидного номера версии, отображаемого где-то 😕

Извините за удар, есть новости о выпуске 19.8? Я очень хочу поиграть с dictConfig :-)

( @ Allu2 См. PR https://github.com/benoitc/gunicorn/pull/1727, чтобы показать номер версии текущего выпуска в README)

Есть новости по этому поводу? Я с нетерпением жду этого, поскольку он устраняет некоторые проблемы с --reload в контейнерах alpine и сделает нашу среду разработки намного лучше!

Я подготовлю релиз. @berkerpeksag @benoitc тебе подходит?

@tilgovi +1 от меня.

Из любопытства, что это за процесс создания релиза Gunicorn?
Этот выпуск, похоже, был отложен на последние 5 месяцев с более чем одним «следующий (день | неделя | скоро)»

@ Allu2

• Обновить журнал изменений
• Отметьте и загрузите
• Сделать релиз на GitHub

Это несложно, но все мы делаем это на добровольных началах.

Я обновил журнал изменений и считаю, что все готово к выпуску.

Я иду спать и отрежу ярлык утром, когда я смогу быть рядом в случае какой-либо ошибки, требующей выпуска последующего патча, но я не ожидаю каких-либо проблем.

Выпущена 19.8.0!

Пожалуйста, прокомментируйте здесь любые отзывы или проблемы!

В будущем мы будем стремиться к более частым выпускам. Ваши запросы на вытягивание и отзывы помогают. Если вы заинтересованы в том, чтобы быть сопровождающим, дайте мне знать!

@tilgovi спасибо! и согласен :) извините, что не ответил в ближайшее время Я ехал весь месяц