[devel] Maintainer's toolbox

[Mikhail Yakshin]

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

Ну, оно само по себе не выработается, если не будет некоего инструмента, 
который бы фиксировал эту практику. То же самое, как сейчас бардак по 
большому счету с выпускающими тэгами из-за отсутствия gear-release.

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

Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы 
можно отредактировать вручную, и TCP-пакеты тоже разослать %)

>>> Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
>>> пакетов структура такая:
>>> git/ALTLinux -- там хранится все пакеты что я отправил на git.alt
>>> git/ALTLinux/asterisk -- все связаное с астериском
>>> git/ALTLinux/appliance -- appliance-*
>>> и т. д. Я не представляю как это сделать пригодным для всех способом.
> MY> Ok, понял, в ближайшее время сделаю такую возможность неплоского
> MY> размещения пакетов.
> MY> determine_package() переделаю так, чтобы он, если указан полный путь
> MY> (типа "ALTLinux/asterisk/some-package") - собирал бы его, если нет - то
> MY> искал бы соответствующую директорию find'ом; если найдена одна - то
> MY> собирал бы оттуда; если их несколько - то ругался бы на то, что не может
> MY> однозначно определить, что собирать (как rpm -e, когда под критерий
> MY> подпадает >1 пакета).
> 
> Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги
> репозиториев смотреть не надо.

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

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

Ссылку на то, что он deprecated, кстати, можно? Там предлагается 
какая-то аргументация?

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

Что-то мне подсказывает, что zsh сейчас у нас не default shell, да и 
даже bash-completions стоят хорошо если у трети народа.

> MY> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
> MY> букв префикса.
> MY> Минусы - чуть медленнее набирать, большая надежда на completion, надо
> MY> продумывать так, чтобы удобно было комплитить и в completion попадали
> MY> только нужные команды.
> MY> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
> MY> мешать друг другу и не ломать копий - все равно это абсолютно вопрос
> MY> привычки/удобства для конкретного человека - предлагаю сделать и так, и
> MY> так - ровно как с опциями (-f и --force). Сделать симлинками или
> MY> алиасами 2 варианта вызова - и длинный, и короткий.
> 
> Понимаешь... в любом случае upper case utilites это зло.

Давай все-таки не смешивать. Есть 3 отдельные темы:

1) Стиль наименования утилит - нужен и "короткий", и "длинный". 
Согласен? У кого-то еще какие-то мнения есть?

2) Upper case для именования утилит. Твое мнение я понял, свое - 
озвучил, есть еще у кого-то какие-то мнения?

 > Тем более что всем этим утилитам место в основном в gear-.* namespace.

3) Предложение убрать разделение на утилиты "низкого уровня" вроде 
gear-*, hsh-* и т.п. и "высокого уровня" - те, что лежат в 
etersoft-build-utils / comfort? Я тогда его совсем не понимаю...

-- 
WBR, Mikhail Yakshin