[devel] ACL in branches

[Alexey Rusakov]

В Втр, 10/03/2009 в 23:22 +0300, Alexey Tourbin пишет:
> On Wed, Mar 11, 2009 at 01:56:45AM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 22:52:04 10.03.2009 UTC+03 when at на altlinux.ru did gyre and gimble:
> > 
> >  AT> Мои оппоненты утверждают, что принципиально важно вручную
> >  AT> протестировать пакет сразу после сборки в girar-builder, но до
> >  AT> попадания в репозитарий.
> > 
> >  AT> Я оппонирую, что это не принципиально важно: можно протестировать
> >  AT> пакет чуть раньше (после сборки в собственном хешере) или чуть
> >  AT> позже (когда пакет уже пройдёт в сизиф).  А тестирование именно
> >  AT> "здесь и сейчас" дополнительно ничего не дает.
> > 
> > В такой постановке - да. Но как я помню - вопрос ставился немного
> > по-другому.
> 
> Вопрос ставился так.  Оппоненты хотят иметь задание, которое собирается,
> но автоматически не проходит.  Когда задание собралось, им отправляется
> уведомление: "задание собралось но не прошло; тестируйте вручную и
> подтверждайте проводить или нет".  Оппоненты тестируют вручную и говорят
> "окей, проводите".  На что сборочница отвечает: "извините, пакеты as is
> взять нельзя, их пришлось пересобрала, тестируйте ещё раз".  И т.д.
> 
> Я утверждаю, что тестирование вручную по фактору сборочной среды дает
> не очень много.  Потому что ещё есть фактор рантайм-компоновки по
> зависимостям.  Оппоненты хотят контролировать фактор изменения сборочной
> среды и надеются, что это им даст дополнительные гарантии.  Но
> контролировать фактор рантайм-копоновки они не могут даже в принципе.
> 
> > Есть сборки, которые не имеет смысла пропускать в сизиф, потому что
> > заранее известно, что они не готовы. Скажем (если взять те пакеты, на
> > которых приводились примеры), там отсутствует путь апгрейда
> > пользовательских данных с Сизифной версии на новую.  Или автор сборки
> > имеет "особое мнение", отличное от мейнтейнера сизифной версии. Или
> > что-то ещё.
> 
> > Такой people-на-стероидах.
> 
> Это другой контекст спора, который касался "персональных дедалов".
> Впрочем, не исключено, что эти конексты связаны (и ещё более не
> исключено, что мы их смешиваем или путаем).
> 
> > Второй вариант использования - карманы для предварительного тестирования
> > перед бранчами, поскольку допускать регрессии в бранчах более опасно,
> > чем в Сизифе.
> 
> Можно собирать у себя в хешере и тестировать.  Я так делаю для многих
> своих пакетов, в которых нет 'make test'.  А пакеты с 'make test' стал
> всё чаще отправлять на сборку без предварительного тестирования в
> хост-системе.
Сборка "у себя в хешере" исключает возможность групповой работы. То есть
если хочется тестировать не в одиночку, а с привлечением
фэн^Wфан^Wгруппы особых любителей, то опять же выкладывать в people.

Вторая составляющая - это если хочется не тестировать, а собирать
группой. Тот же GNOME 2.26 сейчас выкладывается на people одним
человеком; если выкладывать его туда внесколькером, возникнут проблемы
самого разного плана начиная с прав на /pub/people/gnome. А в сущности
всё сводится к тому, что people не обладает фреймворком для сборки
пакетов, это просто файлохранилище.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: Эта часть сообщения подписана цифровой подписью
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090311/86a4f3aa/attachment-0001.bin>