[devel] Sisyphus переименовать в 5.0/5.1 ?

[Evgeny Sinelnikov]

29 апреля 2009 г. 0:04 пользователь Alexey Rusakov <ktirf at altlinux.org> написал:
> В Втр, 28/04/2009 в 23:46 +0400, Evgeny Sinelnikov пишет:
>> Если перейти к конструктиву, то я бы предложил уточнить важный, как
>> мне кажется, момент. Какой из вариантов, мною предложенных (срезы или
>> доп. репозитории), стоит считать генеральной линией партии? Может быть
>> каждый из них требует пояснения или уточнения?
> На данный момент это лишь моё мнение как члена сообщества, но я бы
> предпочёл допрепозитории срезам. Хотя бы потому, что срезы в немного
> другой ипостаси, но уже проходили.

аналогично... И я, как было метко заявлено, уже неоднократно об этом
говорил... :)
Моя просьба сводилась к тому, чтобы предоставить возможность создавать
репозитории под задачи... Интересует нас вопрос "стопудовой
работоспособности гнома" - создаём репозиторий, собираем на нужном
бранче доп. пакеты, тестируем, затем, в зависимости от результата,
исправляем и продолжаем тестировать или перекладываем, ну, на худой
конец, заново пересобираем.

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

Важен механизм, который позволит, например, медленно но верно
оттестировать проблемы переезда на новый python-2.6, обновления
openssl до версии 1.0.0 уже beta2 или krb5-1.7 пока ещё beta1... Всё
это хотелось бы уже видеть, но ещё не в сизифе и по частям с
различными пересечениями...

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

Вся суть в том, что большинство проблем именно комплексные и
протестировать в hasher одному дома их просто не реально...

>> Получается ведь как? Одни знают, но сообщают лишь следствия, а вторые
>> делают, но не знают причин, на основе которых делаются выводы, в
>> озвучиваемых по их результатам следствиях...
>>
>> Где, например, критерий по которому стоит сделать выбор между
>> "fix'ить, что найдется в бранчевском гноме", переложить из сизифа или
>> пересобрать что-то специально для бранча?
>>
>> Где критерий "стопудовой работы"?
> Я полагаю, всё-таки тестирование.

Я тоже...

>> Как, кроме тестирования, это можно выявить?
>>
>> Какие механизмы тестирования для этого предоставлены?
> На данном этапе приложения для GNOME можно тестировать при помощи
> Accerсiser. Изначально это accessibility inspector, но прекрасно
> подходит и для тестирования приложений тоже.
>

Отмечу, что я не верю в Gnome... Взглянул на Accerсiser - по моему,
это не совсем универсальный инструмент, хотя средство интересное...
Кстати, по линке http://live.gnome.org/Accerciser/PluginTutorial в
полях примеров только у одного меня пустые строки показываются? Часто
встречаю это проблему - всё никак не соберусь пожаловаться...

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

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

Прежде всего меняется сам подход к работе. Всё происходит не в ночь,
когда что-то приехало, всё сломали и нужно чинить... А тогда, когда вы
сами запланировали...  Но это у тех, кто поверяет, у остальных всё,
как обычно, только ломаться должно по-реже :)

-- 
Sin (Sinelnikov Evgeny)