BugTracking/DistributionBugTriaging

(Идеальная, но не используемая) инструкция по обработке ошибок и запросов для дистрибутивов

Багтракинг для дистрибутивов достаточно сильно отличается от обработки ошибок в такой подвижной среде, как Сизиф.

Баг на дистрибутив не может быть перевешан на другой дистрибутив, сизиф или бранч

(за очевидным исключением ошибочно открытых багов)

Баг на дистрибутив должен получить resolution в рамках дистрибутива. Это нужно для достижения нескольких целей:

• уменьшения количества дублирующихся багов. Если баг перевешивается с дистрибутива на другой продукт, вероятность заведения дубликатного бага на дистрибутив увеличивается.
• создания полной картины ошибок в дистрибутиве. Если баг перевешивается с дистрибутива, то информация о состоянии дистрибутива дробится и release manager'у и QA manager'у сложнее понять, в каком состоянии находится дистрибутив.
• увеличения полезности багзиллы для пользователей. Если все баги дистрибутива висят на одном продукте, то пользователям проще искать уже известные баги и они меньше будут напрягать разработчиков в рассылках, IRC и жаббере.

Это означает, что во почти во всех ситуациях вместо перевешивания бага на другой продукт правильным будет склонировать баг и указать какой-то resolution:

• Если баг будет исправлен в текущей версии дистрибутива (в апдейтах или патч-релизе), но для этого необходима работа в Sisyphus или бранче, баг необходимо склонировать на Sisyphus/бранч, в исходном баге поставить зависимость на свежесозданный и закрывать баг в дистрибутиве только тогда, когда апдейты или патч-релиз выпущены.
• Если баг будет исправлен в следующей версии дистрибутива, нужно склонировать баг в следующую версию, а в данной закрыть с диагнозом LATER
• Если неизвестно, когда баг будет исправлен, но работа в Sisyphus/бранче по исправлению этого бага запланирована, то баг нужно склонировать в Sisyphus/бранч, а исходный закрыть как LATER с комментарием "смотри bug # по исправлению в нестабильной ветке".