[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Alexey Tourbin]

On Thu, Jun 16, 2005 at 07:36:24PM +0300, Michael Shigorin wrote:
> > Предлагается установить достаточно высокую планку прохождения
> > пакетов в сизиф.  И время от времени её поднимать.
> Юмор оценил.

Это не совсем юмор, я действительно так думаю.  Собственно, если не
технологическое превосходство и не повышенное качество сборки пакетов,
плюс продуманность зависимостей и т.п. -- чем тогда Sisyphus, грубо
говоря, лучше Fedora Core?  По пользовательской базе и по количеству
тестеров-волонтёров Sisyphus всё-таки заметно проигрывает. :)  Значит,
нужно искать "другие" сильные стороны и пытаться их максимльно полно
реализовать, пробовать отчасти заменить ими то, чего нет.

> > По поводу масштабирования, субъективное мнение: никакого
> > масштабирования в ближайшем будущем не будет, лучше попытаться
> > всеми силами вырваться вперед.
> Зачем/как?

Нужны очередные шаги по части улучшения сборки/тестирования пакетов,
а также по части автоматического тестирования репозитария.

Последним крупным достижением по части технологии был hasher (2003),
последним крупным рывком, не очень удачно организованным -- удаление
*.la файлов, примерно в то же время.  Последним мелким достижением
стало появление rpm-build-perl-0.5 (Dec 06 2004). :)

Нужно постоянно что-то улучшать, выискивать новые (потенциальные) ошибки,
рассылать побольше спама и т.п. :)  Если же просто заворачивать новые
версии программ в rpm пакеты и отправлять их в incoming -- тогда это
"застой" какой-то получается, стагнация.  Зачем это нужно?  Новые версии
программ можно и полу-автоматически собирать.  Вон в Мандриве есть
какой-то /usr/bin/rpmbuildupdate из пакета rpm-rebuilder:

rpmbuildupdate: download and rebuild the new version of a given srpm.

Id: 1463
Я как-то жене на пальцах объяснял, чем я тут время от времени занимаюсь:
скачиваю программы из разных мест и закачиваю их в ALT Linux; мне пока
решительно не понятно, почему эта нехитрая трансформация влечет за собой
юридические последствия. :)
                -- at in devel@
%

> > Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core" можно
> > было с чистой совестью ответить: "всем"
> Да ладно, хватает "works for me".

Нужно пытаться делать самое лучшее.
А иначе лучше ничего не делать и пользоваться тем, что уже есть.

> > Вперёд можно вырваться только за счет технологического
> > превосходства.
> Да нет, те же RH и SuSE IMVCO впереди исключительно за счёт
> организационного превосходства.  Где-то на wiki есть мои
> плевательства про их спеки, я уж не говорю про порезку пакетов 
> и вагон всего прочего.

Организационное превосходство -- это совсем другая тема.  Здесь есть
очень много вопросов и очень мало внятного было сказано.  "Нужно решить
проблему взаимодействия фирм и сообщества" -- "нужно решить проблему
голода в странах Африки и найти лекарство от рака".  Я для себя эту
проблему "решил" так: дистрибутивы ALT Linux меня не интересуют, потому
что это откусывание времени на тупиковую ветку развития с низкой отдачей
для сизифа.  (Здесь также актуальны вопросы критического количества
инсталляций, ради которого стоит поддерживать отдельную ветку,
платежеспособного спроса на поддержку и т.д.)

Со временем, наверное, что-то изменится.  Это не по моей части.

> Анализ пакета.  Как минимум процесс раздирания пакета на запчасти
> -- точно. (речь не только о коде, но и о дубликации процессов)

Надо посмотреть.  Посмотрю.

> > Для RPM нужен legacy mode -- чтобы при сборке пакетов в частном
> > порядке не приходилось вникать в особенности ALT полиси.
> Ммм... это с отрывом большинства/всех проверок, не
> предусмотренных в голом upstream?

Да.  Грубо говоря, чтобы значительная часть редхатовских src.rpm пакетов
собиралось; вернее, чтобы их сборка заканчивалась. :)

> > Более серьезная претензция как раз по части .la файлов -- не
> > собираются KDE'шные приложения без хака на configure и т.п.
> > Если совместимости на уровне RPM никто не гарантировал, то
> > несовместимость на уровне GNU autotools -- это уже некий
> > показатель.
> Скажем так -- нигде эти несовместимости толком вместе не описаны.

Несовместимость на уровне GNU autotools -- это вообще нонсенс,
ведь GNU autotools и предназначены в первую очередь для достижения
совместимости на всём и вся.  Ну я уже изложил "по пункатам".

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

Долой фирмы!  Даешь светлое будущее! :)

> Так вот как раз с языковым-то проще, когда особенности ясно
> собраны и понятно, что подсовывать переводчикам -- а в остальном
> годится типичная базарная документация с гугля. (ну, где-то)

С языком как раз плохо.  Население ex-USSR -- это примерно 200 млн.
человек, население планеты -- примерно 6 млрд.  То, что мы тут пишем,
в состоянии понять только 3% населения планеты, вернее, примерно такой
же процент потенциально заинтересованных разработчиков.

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

> Так тут вторая сторона ордена -- какую надо иметь квалификацию,
> чтобы откопать корень проблемы и порешать его?  Дима -- *Дима* --
> вон как-то обошёлся в ответе без слова "тривиально".

Не понял про "тривиально".  Но мы же здесь "хакеры", да?

> > Так вот, просто предлагается ликвидировать целый класс
> > потенциальных ошибок.  Перфекционизм это или нет, я не знаю.
> Это хорошее дело, если для contrib оно не будет вменяться в
> обязанность.  В зависимости от высоты планки для base и
> прилежащих компонент -- _там_ вполне может.  По крайней мере 
> я был бы за.

Я против понижения статуса contrib, ведь большинство пользователей
Sisyphus сейчас использует SRPMS.classic.  Если же удалить contrib
из настроек apt по умолчанию, то это спровоцирует дальнейшее падение
статуса contrib, сделает из него отстойник.

Собственно, я не понимаю, в чем проблема.  Сейчас будет добавлена новая
проверка, и робот будет слать спам.  Будет 5 месяцев на исправление.
Через 5 месяцев большая часть пакетов будет hopefully исправлена,
меньшая уйдёт в orphaned и затем hopefully сменит maintainer'ов.  То
есть через 5 месяцев мы сможем сказать, что такой-то класс потенциальных
проблем в сизифе исправлен.

Если кому-то обидно получать спам как надругательство над результатами
своей работы, то это заслуживает отдельного разъяснения.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20050617/400fa957/attachment-0001.bin>