[devel] Продолжение тестирования installer

Денис Смирнов =?iso-8859-1?q?mithraen_=CE=C1_altlinux=2Eru?=
Вт Июл 26 01:45:03 MSD 2005


On Mon, Jul 25, 2005 at 06:30:56PM +0300, Michael Shigorin wrote:

MS> предлагаю понимать, что Compact 3.0 вынужден решать вполне
MS> конкретные проблемы во вполне сжатые сроки.  При этом задачи
MS> достаточно специфические, чтобы итог был реально малополезен
MS> большинству населения devel@/sisyphus@, увы.

Да, это понятно.

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

Важно другое -- чтобы дистрибутив был достаточно оттестирован. История с
последнем мастером, где пусть мелкие но элементарно выявляемые
тестированием ошибки были опубликованы сразу после релизом портит
репутацию как ООО, так и team. А это ценный ресурс, я скажу.

MS> ещё предлагаю не пытаться навязывать решение всех поставленных
MS> нами тут проблем выпускающим Compact 3.0, но на базе бранча 3.0
MS> выпустить "team edition", как бы это не называлось.

А вот для этого как минимум _необходимо_, чтобы хотя бы инфраструктура 3.0
разрабатывалась общедоступно. Было радостно что этот процесс развивался

MS> с серверным применением -- на сейчас не могу предположить выпуска
MS> на базе 3.0 чего-то скольл-нибудь поддерживаемого, поэтому по
MS> крайней мере сейчас сам скорее ориентируюсь на 3.1 и весну 2006.

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

Конкретно сегодня я пытался сепаратором сформировать свой мини-дистрибутив
из-за одной маленькой проблемы -- имеется сервер с контроллером от 3ware,
куда Мастер 2.4 просто не встал. Инсталлятор таки встал.

>> Хочу вас всех обрадовать.
MS> Да ничего особенно нового.

У нас уже год как ничего нового в плане ситуации нет. Есть одни и те же
темы часто поднимаемые. Я предлагаю наиболее критичные в ближайшие
месяц-два вопросы разрулить.

>> логичным вижу выпуск 2 раза в неделю -- с утра во вторник
>> (после синхронизации изменений, сделаных в понедельник) и с
>> утра в четверг.
MS> Логично (при наличии ответственного за следующий пункт) -- 
MS> раз в неделю, а то и две. (вспомни бета-тестирование ALM24)

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

>> 2. Усилить контроль над процессом разработки инсталлера
MS> Силой воли?  (если нет -- объясни механизм)

Например сформировав и ежедневно публикуя простой отчёт, на базе нынешнего
по багам -- а именно сроки, в течении которых бага подтверждается или
отвергается. А также сроки, в течении которых бага фиксится после
подтверждения.

Это позволит как минимум выявить баги, которые конкретный мантейнер не
может/не хочет/не успевает решить. Возможно в этом случае будет проще
элементарно помочь.

>> 4. До момента закрытия всех багов инсталлятора выпускать любые
>> альфы/беты/rc Compact базируясь исключительно на текущем
>> Сизифе, чтобы любой человек, синхронизирующий у себя Сизиф, мог
>> выпекать и тестировать инсталлятор.
MS> Нифигасе фриз.  Впрочем, о том, что есть бранч 3.0, уже даже
MS> дважды стало известно (правда, оба раза голосом). :)

_текущем_, а не _сегодняшним_. Выпекаем сегодня -- делаем на базе сегодня.

Фриз пакетной базы это одно. Фриза инсталлера и иже с ним, как я понимаю,
сейчас быть не может, или я ошибаюсь?

>> Сейчас я не могу себе позволить передать на тестирование
>> инсталлер кому-либо из не являющихся членом Team.  Потому как
>> их естественный вопрос будет -- "А что, это требует
>> тестирования? Какого? Вы это хоть раз запускали?".
MS> Это причина, по которой даже не стал пытаться искать возможность
MS> объезда вылета разбивалки 2.9.12 при попытке удаления раздела...
MS> Договорённость с железячниками про тестирование (звук/видео/SATA)
MS> была просто отложена.

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

Да, я недаюсь ты понимаешь что я это совсем не тебе говорю. Потому как ты
это всё знаешь много лучше меня.

Собственно в этой теме флеймить не о чем. Я предложил несколько, пусть
спорных, но решений. Очень прошу обратить на них внимание, или, ещё лучше,
предложить более эффективные решения.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> 4. Целесообразен ли в нынешнем состоянии ядер переход на 2.6 ?
it depends. В большинстве случаев нецелесообразен.
		-- lakostis in community@




Подробная информация о списке рассылки Devel