From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <45C3595A.1080602@altlinux.org> Date: Fri, 02 Feb 2007 18:31:38 +0300 From: Mikhail Yakshin User-Agent: Thunderbird 1.5.0.5 (X11/20060822) MIME-Version: 1.0 To: ALT Devel discussion list References: <20070128051043.GA8647@mw.local.seiros.ru> <45BCBD9D.2000608@altlinux.org> <20070129184508.GA8783@mw.local.seiros.ru> <45BE58BC.8060602@altlinux.org> <20070130115510.GA2088@mw.local.seiros.ru> <45C06DD7.9070906@altlinux.org> <20070131124213.GF6627@mw.local.seiros.ru> <45C26BA6.7060203@altlinux.org> <20070201235832.GA16720@mw.local.seiros.ru> <45C302A1.7090806@altlinux.org> <20070202145906.GC10430@mw.local.seiros.ru> In-Reply-To: <20070202145906.GC10430@mw.local.seiros.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] Maintainer's toolbox X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2007 15:32:54 -0000 Archived-At: List-Archive: List-Post: Денис Смирнов пишет: > 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