[devel] ALT Linux [Team] QA (was: "LATER" в Сизифе)

[Michael Shigorin]

On Sun, Feb 17, 2008 at 10:19:44AM +0300, Alexey Rusakov wrote:
> > > LATER в Сизифе означает "потом пофикшу". Всё бы ничего, да
> > > только баг при этом закрывается, и пропадает из поля зрения
> > > как майнтайнера, так и юзеров.
> > Про него помнят qa robot и my bugs ;)
> За всю активную жизнь разработчика ALT Linux я стоолько раз
> открывал my bugs... У активных мейнтейнеров там ты лучше меня
> знаешь сколько багов лежит. Не очень продуктивно.

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


Проблема номер раз -- у нас многие майнтейнеры физически
перегружены багрепортами.  Просто страшно в список заглядывать.

Могу попросить тех, кому небезразлично, помочь с проверками
багов, которые висят на zerg@ и vsu@ -- зачастую они по факту 
уже исправлены, но багрепорты висят открытыми и заваливают те,
которые бы стоило посмотреть.

  (btw источник этой проблемы -- многофакторный, но обычно
  обсуждение ряда из них приводит к флейму и обидам, поэтому
  лучше постараюсь при очередном складывании картинки в голове
  запихать её на вики и предложить откомментировать/исправить)

Сам как-то озадачился и свёл свои баги примерно к трём десяткам,
но эти уже -- висяки в основном.


Проблема номер два -- сизиф сейчас пытается быть аэробусом,
целиком собранным до микрона.  Очень дорого, а для передвижных
столиков при этом неосмысленно.

  (уже запыхался о ней говорить)

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

Это определяется тем, что:
- люди в команде -- разные, и не все из нас ldv@ или lav@;
- фактическая критичность пакетов -- разная; 
- фактическая компетентность апстримов -- тоже разная.

Сборочное замыкание -- разумеется, main на main, contrib --
на main+contrib.

Так вот при этом main следует по возможности поддерживать не
только силами команды, а и силами заинтересованных в "горячем"
качестве фирм.  Например, чтоб lazarus не приходилось спешно
фиксить, а было понятно -- если он лежит в contrib, то пакет
необязательно заявлен как соответствующий самым-самым высоким
стандартам или вообще активно используемый майтейнером в быту.

Бишь баги на пакеты из main стоит обязать проверять и при
необходимости (когда принято решение о важности баги с т.з.
соответствующей фирмы -- пока это по факту ООО "АЛТ", боюсь)
предлагать помощь или в случае исчезновения контакта --
подготавливать NMU (с уведомлением, что пакет из main является
unmaintained).

Например, если бага повешена и висит неделю (major+), месяц
(normal), три месяца (minor-) без движения в UNCO/NEW, то по
крайней мере обеспечить её просмотр QA Team.  Даже если
в составе одного выделенного разработчика.


Это всё тоже напрашивается на некую концепцию обеспечения
сочетания качества и интереса при совместной открытой разработке
людьми на fulltime в профильных фирмах и заинтересованными "для
себя" добровольными участниками проекта, но я не уверен, время ли 
для такого текста: он-то упирается в этого самого хотя бы одного, 
но терпеливо помогающего QA Team member.


> В общем, я согласен с dottedmag@, проблема актуальна.

Актуальна другая проблема: когда багзила становится уже не
инструментом, а ещё одним рефлекторно избегаемым сайтом.

> > REOPEN им делается в подавляющем большинстве случаев для
> > закрытия сразу же как WONTFIX (~80%) или FIXED/WORKSFORME
> Ну так это же тоже не годится. Дополнительное телодвижение там,
> где от него можно избавиться.

Боюсь, "можно" -- это несколько оптимистично...

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/