Re: [devel] Maintainer's toolbox

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 5373 bytes --]

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. Это --
базовые утитилы. Остальное обертки.

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

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

>> Разумно. Только с 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.

На перловке я знаю как написать чтобы это работало (не обходить лишние
каталоги), а вот как на шелле -- увы не знаю.

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

Это в этом листе озвучивал ldv@

> MY>> В качестве чуть альтернативной реализации - это когда делается одна
> MY>> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый
> MY>> параметр - команда, которую надо выполнить. Удобно, если есть умный
> MY>> комплишен а ля zsh или bash-completions, довольно неудобно, если нет.
>> Ага.
MY> Что-то мне подсказывает, что zsh сейчас у нас не default shell, да и 
MY> даже bash-completions стоят хорошо если у трети народа.

Это отдельная тема все-таки.

> MY>> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
> MY>> букв префикса.
> MY>> Минусы - чуть медленнее набирать, большая надежда на completion, надо
> MY>> продумывать так, чтобы удобно было комплитить и в completion попадали
> MY>> только нужные команды.
> MY>> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
> MY>> мешать друг другу и не ломать копий - все равно это абсолютно вопрос
> MY>> привычки/удобства для конкретного человека - предлагаю сделать и так, и
> MY>> так - ровно как с опциями (-f и --force). Сделать симлинками или
> MY>> алиасами 2 варианта вызова - и длинный, и короткий.
>> Понимаешь... в любом случае upper case utilites это зло.
MY> Давай все-таки не смешивать. Есть 3 отдельные темы:
MY> 1) Стиль наименования утилит - нужен и "короткий", и "длинный". 
MY> Согласен? У кого-то еще какие-то мнения есть?
MY> 2) Upper case для именования утилит. Твое мнение я понял, свое - 
MY> озвучил, есть еще у кого-то какие-то мнения?
>> Тем более что всем этим утилитам место в основном в gear-.* namespace.
MY> 3) Предложение убрать разделение на утилиты "низкого уровня" вроде 
MY> gear-*, hsh-* и т.п. и "высокого уровня" - те, что лежат в 
MY> etersoft-build-utils / comfort? Я тогда его совсем не понимаю...

gear-* это не низкий уровень. Вообще-то это обертка над git и некоторыми
другими утилитами. Точно так же как etersoft-build-utils.


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

http://freesource.info
----------------------------------------------------------------------------
Т.к. Compact уже выпущен, то все что не успели исправить - ошибками
не считается.
		-- rider in #3005

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]