8. Сопровождение пакета в течение жизненного цикла

Maintenance update для Leap - это не "залить новую upstream версию". Политика: маленькие self-contained patches, совместимость, отсутствие новых зависимостей, отсутствие новых подпакетов без необходимости. Security bugs обычно подходят для update; обычные bugs проходят оценку риска.

Maintenance workflow:

osc mbranch foo
cd home:LOGIN:branches:openSUSE:Maintenance/foo.openSUSE_Leap_16.0_Update
# apply patch, update .changes
osc build openSUSE_Leap_16.0 x86_64 foo.spec
osc vc
osc ci -m "Fix boo#123456 CVE-2026-12345"
osc mr

Patchinfo example:

<patchinfo>
  <packager>LOGIN</packager>
  <category>security</category>
  <rating>important</rating>
  <summary>Security update for foo</summary>
  <description>This update fixes an out-of-bounds read in foo.</description>
  <issue tracker="boo" id="123456"/>
  <issue tracker="cve" id="CVE-2026-12345"/>
</patchinfo>

Leap 16.x: для stable release major version bump запрещён по умолчанию. Исключение возможно, если backport сложнее и риск новой версии ниже; это должно быть явно объяснено в .changes и maintenance request.

Tumbleweed: регулярные version updates допустимы, но через Factory review, staging, repo-checker и openQA. Если пакет ломает rebuild consumers, его задержат в staging или вернут.

Slowroll: изменения приходят волнами из Tumbleweed/Factory. Для packager-а это значит: сначала добейся корректности в Factory, затем проверяй, не застрял ли пакет/зависимости в Slowroll project.

Factory staging: ring 0/1 packages идут через staging с openQA; non-ring packages могут идти через ADI staging, где обычно проверяется buildability.

Где искать дополнительно