[devel] развитие дистрибутива

[Денис Смирнов]

On Sat, Mar 13, 2010 at 03:18:37PM +0300, Aleksey Novodvorsky wrote:

AN> Я не стал бы ставить здесь квантор общности. Несомненно, нам сейчас
AN> надо синхронизировать не только версии, но и патчи для проблемных
AN> пакетов, у которых нет постоянных и активных мейнтейнеров. Вместе с
AN> тем там, где такие мейнтейнеры есть, мы можем и должны делать так, как
AN> считаем лучше. Учитывая чужой  опыт, грабли etc.

Безусловно. Иначе это будет "пересобранная fedora", т.е. "fedora + hasher
+ girar", а такой проект вообще никому не нужен. Сформулирую тезисами свою
позицию:

По поводу качества:
1. Неидеальный пакет это лучше чем /dev/zero.

2. Даже хреново собранный пакет, это лучше чем /dev/zero

3. И даже импортированный в полностью автоматическом режиме с помощью
робота пакет из Fedora это _лучше_ чем /dev/zero

4. Я понимаю, что некоторая степень жесткости в репозитории необходима
элементарно для борьбы с разгильдяйством. И я помню, каких пинков получил
от ldv@ по доработке Asterisk перед выпуском 4.0 -- и если бы не эти
пинки, те мелкие грабли еще долго были бы не исправлены. Так что некоторая
степень жесткости, что считать мусором который пропускать нельзя --
необходима.

5. Излишние требования к пакетам приводят к потере мантейнеров, а значит к
тому что пакеты становятся еще хуже.

6. Понятие "излишние" индивидуальны. Скажем security бага в ядре это
blocker, по моему мнению достаточный для немедленного выбрасывания этого
ядра из репозитория (если оно не исправлено). Однако мантейнер wks flavour
считал иначе -- и у нас теперь в Сизифе нет wks flavour. И это у нас в
team любимые грабли, которые топчутся уже не один год, и адекватного
решения не придумано. Вернее придумано одно -- 'contrib', т.е. 'мы тут
какую-то фигню собрали, пользуйтесь на свой страх и риск, но никто ни за
что тут не отвечает'. И это не реализовано. Сколько мантейнеров нам надо
потерять еще, чтобы сделать contrib мне весьма любопытно.

7. Политика "мантейнер должен быть хакером" мне категорически не нравится.
Хорошо если мантейнер -- хакер. Но я собирал один единственный пакет в
таком "хакерском" режиме (с ежедневным полным вычитыванием багтрекера и
всех svn commits в репозитории, написанием своих security и
стабилизирующих патчей, и т.д.). Это пакет asterisk1.4. Через год выгорел
настолько, что сейчас не в состоянии этот пакет поддерживать в актуальном
состоянии, со всеми теми моими патчами. И сейчас думаю убить этот старый
астериск вообще из репо, или просто собрать vanilla, и не париться.

Безусловно круто, если team состоит из нескольких сотен ldv@ :) Но, увы,
это невозможно. Поэтому средненькие пакеты -- были, есть и будут. И с этим
стоит смириться. Все что можно сделать -- это пытаться изменить какие
пакеты поддерживаются сколь квалифицированными мантейнерами и в каком
режиме.

8. Anti AI крики в рассылке выглядят откровенно глупо. Да, человек
собирает пакеты круче. А скрипт -- быстрее. дешевле, и во много раз
больше. А еще он не ест, не спит, не устает, и не делает очепяток. Потому
считаю что единственный выход маленькой команде иметь конкурентноспособное
решение -- активно использовать автоматизацию. 

Это основное что я хотел сказать в этом треде. Выжимка:
- нужен contrib;
- нужны pocket'ы (чувствую что с этими словами меня уже можно заменить
  cron'ом)
- подумать об автоматизации импортирования пакетов, которые никем не
  поддерживаются из той же Fedora;
- дорешать проблему с arepo. Вот недавно очередной знакомый спец сказал
  что альт фигня, fedora рулез. Просто потому, что в x86_64 систему там он
  установил skype, а у нас -- нет, и пакетов у нас в arepo skype не
  хватило;

AN> В любом случае, не стоит дискуссию о конкретной подсистеме подменять
AN> рассуждениями об общем.

К сожалению это было уже другое обсуждение под тем же subj'ем. Исправил.

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

http://mithraen.ru/
----------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20100316/43225cf8/attachment-0001.bin>