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

[Aleksey Novodvorsky]

On 2/17/08, Michael Shigorin <mike на osdn.org.ua> wrote:
> 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 источник этой проблемы -- многофакторный, но обычно
>   обсуждение ряда из них приводит к флейму и обидам, поэтому
>   лучше постараюсь при очередном складывании картинки в голове
>   запихать её на вики и предложить откомментировать/исправить)
>
> Сам как-то озадачился и свёл свои баги примерно к трём десяткам,
> но эти уже -- висяки в основном.

Да, координировать это нужно QA.

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

Не согласенм в части требований к сборке, это всегда осмысленно. Иначе
получим нынешний Cooker и не расхлебаем.
Если речь о другом -- поясните.

>
>   (уже запыхался о ней говорить)
>
> Может иметь смысл разделять main, где качество держать на
> предельно возможной разумными средствами планке (возможно,
> даже чуть выше, чем сейчас выбирается для всего сизифа).
> И contrib, где планка может и должна быть ниже.
>
> Это определяется тем, что:
> - люди в команде -- разные, и не все из нас ldv@ или lav@;
> - фактическая критичность пакетов -- разная;
> - фактическая компетентность апстримов -- тоже разная.
>
> Сборочное замыкание -- разумеется, main на main, contrib --
> на main+contrib.
>
> Так вот при этом main следует по возможности поддерживать не
> только силами команды, а и силами заинтересованных в "горячем"
> качестве фирм.  Например, чтоб lazarus не приходилось спешно
> фиксить, а было понятно -- если он лежит в contrib, то пакет
> необязательно заявлен как соответствующий самым-самым высоким
> стандартам или вообще активно используемый майтейнером в быту.
>
> Бишь баги на пакеты из main стоит обязать проверять и при
> необходимости (когда принято решение о важности баги с т.з.
> соответствующей фирмы -- пока это по факту ООО "АЛТ", боюсь)
> предлагать помощь или в случае исчезновения контакта --
> подготавливать NMU (с уведомлением, что пакет из main является
> unmaintained).
>
> Например, если бага повешена и висит неделю (major+), месяц
> (normal), три месяца (minor-) без движения в UNCO/NEW, то по
> крайней мере обеспечить её просмотр QA Team.  Даже если
> в составе одного выделенного разработчика.
>
>

Да.

Rgrds, Алексей

> Это всё тоже напрашивается на некую концепцию обеспечения
> сочетания качества и интереса при совместной открытой разработке
> людьми на fulltime в профильных фирмах и заинтересованными "для
> себя" добровольными участниками проекта, но я не уверен, время ли
> для такого текста: он-то упирается в этого самого хотя бы одного,
> но терпеливо помогающего QA Team member.
>
>
> > В общем, я согласен с dottedmag@, проблема актуальна.
>
> Актуальна другая проблема: когда багзила становится уже не
> инструментом, а ещё одним рефлекторно избегаемым сайтом.
>
> > > REOPEN им делается в подавляющем большинстве случаев для
> > > закрытия сразу же как WONTFIX (~80%) или FIXED/WORKSFORME
> > Ну так это же тоже не годится. Дополнительное телодвижение там,
> > где от него можно избавиться.
>
> Боюсь, "можно" -- это несколько оптимистично...
>
> --
>  ---- WBR, Michael Shigorin <mike на altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel