Комунікація після випуску

Команда Release Comms Kubernetes (частина SIG Release) займається анонсами випусків, які публікуються у головному блозі проєкту.

Після кожного релізу команда Release Comms на певний час перебирає на себе ведення головного блогу і публікує серію додаткових статей, щоб пояснити або оголосити про зміни, повʼязані з цим випуском. Ці додаткові статті називаються пост-релізними коментарями.

Підписка на розсилку після випуску

Під час циклу випуску, як учасник, ви можете підписатися на розсилку повідомлень про майбутні зміни у Kubernetes.

Щоб приєднатися, ви відкриваєте чернетку, placeholder pull request (PR) у k/website. Спочатку це може бути порожній комміт. Згадайте про проблему KEP або іншу проблему покращення Kubernetes в описі вашого PR-заповнювача.

Коли ви відкриваєте draft pull request, ви відкриваєте його у гілці main як базовій, а не у гілці dev-1.34. Це відрізняється від процесу для майбутніх змін у випуску та нових можливостей.

Ви також повинні залишити коментар до відповідного тікета kubernetes/enhancements з посиланням на PR, щоб повідомити команду Release Comms, яка керує цим випуском. Ваш коментар допоможе команді побачити, що зміна потребує анонсування і що ваша SIG погодилася на це.

Крім того, в ідеалі вам слід звʼязатися з командою Release Comms через Slack (канал #release-comms), щоб повідомити їм, що ви це зробили і хочете приєднатися до неї.

Підготовка вмісту статті

Вам слід дотримуватися звичайного процесу подання статті, щоб перетворити ваш PR-заповнювач на щось готове для рецензування. Однак, для коментарів після релізу у вас може не бути друга по написанню; натомість, команда Release Comms може призначити члена команди, який допоможе вам керувати тим, що ви робите.

Ви повинні зробити squash для комітів у вашому push request; якщо ви не знаєте, як це зробити, абсолютно нормально звернутися за допомогою до Release Comms або команди блогу.

За умови, що ваша стаття позначена як чернетка (draft: true) у front matter, PR може бути обʼєднаний у будь-який час протягом циклу випуску.

Публікація

Перед самим релізом команда Release Comms перевіряє готовність контенту (якщо він не готовий до встановленого терміну, і ви не отримали виняток, то анонс не буде включений). Вони складають графік виходу статей і відкривають нові pull requestʼи, щоб перетворити ці статті з чернеток на опубліковані.

Затверджувачі команди блогу все ще надають остаточний дозвіл на просування контенту від чернетки до прийнятого до публікації. Напередодні дня релізу, PR (або PRʼи) для публікації цих анонсів повинні мати LGTM («мені подобається») і затверджені мітки, а також мітку do-not-merge/hold, щоб гарантувати, що PR не буде злито занадто рано.

Реліз-команда/команда релізу може потім «розблокувати» цей PR (або набір PRʼів), як тільки Git-репозиторій вебсайту буде розморожено після фактичного релізу.

У день, коли кожна стаття запланована до публікації, автоматизація запускає збірку вебсайту, і стаття стає видимою.