Re: [devel] Maintainer's toolbox

[Mikhail Yakshin <greycat@altlinux.org>]

Денис Смирнов пишет:
> On Fri, Feb 02, 2007 at 12:21:37PM +0300, Mikhail Yakshin wrote:
> 
>>>>> Ещё пока не выработалась схема по правильной работе с патчами в git.
>>>>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
>>>>> при использовании git это очень нехорошо.
>> MY>> Значит, нам нужен как минимум обратный инструмент - который после
>> MY>> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.
>>> См. первую строчку моей цитаты. Выработается -- можно будет писать.
> MY> Ну, оно само по себе не выработается, если не будет некоего инструмента, 
> MY> который бы фиксировал эту практику. То же самое, как сейчас бардак по 
> MY> большому счету с выпускающими тэгами из-за отсутствия gear-release.
> 
> Ты её сначала придумай и документируй. Мне -- слабо.
> Смотреть при этом рекомендую на новую систему сборки ядер, это
> _единственный_ образец в сизифе более-менее удобной работы со множеством
> патчей в отдельных бранчах.

Хорошо, посмотрю.

>>>>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
>>>>> не должен лежать там же где все остальное. Потому что он хочет svn,
>>>>> который не всем нужен.
>> MY>> Нам хотя бы один базовый пока набросать %)
>>> Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все
>>> остальное -- вариации на тему :)
> MY> Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы 
> MY> можно отредактировать вручную, и TCP-пакеты тоже разослать %)
> 
> Ты преувеличиваешь.
> 
> Для базовой сборки пакетов достаточно gear, rpm-build и hasher. Это --
> базовые утитилы. Остальное обертки.

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

 > gear-* это не низкий уровень. Вообще-то это обертка

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

> Ещё есть etersoft-build-utils, которая обертка, но как раз оборачивает
> наиболее частые действия. В общем-то сейчас я совершаю ой как мало
> действий которые не автоматизируются этим набором. Когда вся сборка будет
> через git, таких действий будет ровно 0.

Ну, вот для меня ее явно не хватило именно в плане взаимодействия с git 
и появилось то, что появилось.

> Так что речь идет о высокоуровневых утилитках, или утилитках для
> специфических _разных_ workflow для разных _особых_ задач. Как например
> тот же svn-импорт.

Я попробую описать в ближайшее время некоторые примерные workflow, как я 
их себе представляю, ладно?

>>> Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги
>>> репозиториев смотреть не надо.
> MY> Ну, если будет тормозить - ограничим по -depth что-нибудь. Чтобы не 
> MY> хватал лишнего - будем следить, чтобы в каталоге репозитария был .git.
> 
> [mithraen@mw git]$ time find | wc -l
> 0.33user 1.06system 0:57.24elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+349minor)pagefaults 0swaps
> 187150
> 
> :)
> 
> Это при том что оно почти все в кэше, и там RAID 0+1.
> 
> На перловке я знаю как написать чтобы это работало (не обходить лишние
> каталоги), а вот как на шелле -- увы не знаю.

time find -maxdepth 3 | wc -l
?

>> MY>> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
>> MY>> максимально описательны. Возникает проблема completion space. Фактически
>> MY>> обязательно использование completion. Как правило, вводится некий
>> MY>> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).
>>> А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
>>> примеру. Вот как раз для удобного разделения completion namespace.
> MY> Ссылку на то, что он deprecated, кстати, можно? Там предлагается 
> MY> какая-то аргументация?
> 
> Это в этом листе озвучивал ldv@

ldv@, при всем моем уважении, насколько я знаю, не входит в число 
разработчиков-идеологов git. Можно ссылку на какую-то статью, roadmap, 
письмо в http://marc.theaimsgroup.com/?l=git или что-то такое, где 
официально заявляется о том, что они deprecated и будут убраны в 
таком-то релизе?

-- 
WBR, Mikhail Yakshin