From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,FUZZY_XPILL autolearn=no version=3.2.5 Date: Tue, 16 Jun 2009 13:36:11 +0300 From: Michael Shigorin To: ALT Devel discussion list Message-ID: <20090616103611.GT28185@osdn.org.ua> Mail-Followup-To: ALT Devel discussion list References: <4A36DC85.7080704@altlinux.ru> <20090616000055.GE28555@wo.int.altlinux.org> <4A373FEA.8040205@altlinux.com> <20090615223338.GA28555@wo.int.altlinux.org> <87fxe1w2f5.fsf@vertex.dottedmag.net> <20090615230039.GB28555@wo.int.altlinux.org> <87bpopw100.fsf@vertex.dottedmag.net> <20090615232538.GC28555@wo.int.altlinux.org> <4A36DC85.7080704@altlinux.ru> <20090616000055.GE28555@wo.int.altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090616033723.GA4667@mw.office.seiros.ru> <921f6bb40906151715x72157e9bxa93d3bfdf24b5162@mail.gmail.com> <4A36E4F6.1010100@altlinux.ru> <4A36D97D.1050901@altlinux.ru> <4A373FEA.8040205@altlinux.com> <20090616000055.GE28555@wo.int.altlinux.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [devel] =?koi8-r?b?0NLPIMHX1M/NwdTJ3sXTy8/FIMkg0tXezs/FINTF09TJ?= =?koi8-r?b?0s/Xwc7JxSDQwcvF1M/X?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 10:36:26 -0000 Archived-At: List-Archive: List-Post: содержание ~~~~~~~~~~ * mithraen, sin: в [[Pockets]] допишите, чтоб не по архивам * ldv: это всё твоя гениальная идея ;) * rider: ...плюс нотификация всей страны * legion: а давай попробуем у себя? * sin, at: и новички с peer review сюда же * sin: о маргинальности * mithraen: распределённость и A&A; ресурсы; усложнение ли * ldv: о значимости преимуществ On Tue, Jun 16, 2009 at 04:00:55AM +0400, Dmitry V. Levin wrote: > > Разумеется. Тут ты прав. Ничто не мешает тестировать свои > > сборки отдельно. Просто дальше возникает следующий вопрос: зачем мучиться их куда-то вливать? > > Насколько я помню, когда-то цель git.alt была помощь в > > совместной разработке. > Хостинг git-репозиториев подразумевает и помощь в совместной > разработке (в т.ч. подписка на уведомления об изменениях). > Да и сборка пакетов (в т.ч. shared tasks) тоже. Вот и при централизованном кармановодстве это всё заметно проще в реализации, насколько понимаю. Т.е. для совсем распределённой системы, скорее всего, сразу потребуется распределённая аутентификация и авторизация. > > Так вот и "карманы" нужны для упрощения работы разработчиков Сизифа. > В этом вся соль. Прийти бы к взаимопониманию, какие карманы > какой формы нужны По части формы -- просьба к понявшим, чего им-то надо, фиксировать здесь: http://www.altlinux.org/Pockets (перетащил список свойств из Contrib). 2 mithraen, sin: и вы тоже :) > кто их реализует и внедрит. Я берусь помочь с тестированием реализации (и, возможно, смогу помочь с кодом, но пока не строил и не вычитывал подобные системы, сложно сказать). Если вдруг будет удобно получаться и распределённость, то есть некоторые ресурсы, которые возможно подключить к сборке (вероятно, это было бы удобней всего киевской части команды, для которой уже года два как надеюсь сделать здесь сборочный сервер). Проверять у меня точно можно. Как вот и alt.linux.kiev.ua был. Дим, вообще это всё твоя идея, она тебе уже приходила в голову: http://lists.altlinux.org/pipermail/devel/2008-July/157594.html :) On Tue, Jun 16, 2009 at 10:47:06AM +0400, Anton Farygin wrote: > я бы стал пользоваться "карманами", в которых будут собираться > новые версии пакетов, и которые пока нестабильны для попадания > в центральный репозиторий. Или "уже работает для меня", но лучше погонять подготовленным составом перед вываливанием и на не ожидающий. По крайней мере попытка поддержки и отслеживания Sisyphus changes скорее заглохла, причём не в последнюю очередь из-за обычного "так что ж вы, даже в changes не читали? -- нет..." > usecase примерно таков: > мейнтейнер xorg делает shared "карман" xorg-2.0 > дальше все операции типа task и build принимают в виде опции > имя кармана. другие мейнтенеры так-же имеют возможность > создать подобный task, результат которого попадёт в карман > xorg-2.0. Здесь не совсем понятна степень публичности карманов по записи в пределах команды, но это можно или посмотреть на практике, или предполагать возможность переключения изначально. > Собранные пакеты попадают в отдельный репозиторий, который можно > подключить к apt'у и поставить из него всю бороду пакетов. Здесь есть очень важный момент: в отличие от Daedalus и более близко к одному из вариантов использования people, обновление и тестирование получается _узконаправленным_. Т.е. нет опасения, что забыв карман xorg-2.0 подключенным, ты получишь из него firefox-4.0. С дедалом такое было возможно, сам разок нарвался. При этом у people исключительно ручная нотификация, а также затруднения с совместной работой (мне известен один прецедент обратного -- /people/gnome/ -- и неизвестна цена его создания). Мне уже это отличие от тестирования изменений всего используемого подмножества Sisyphus сразу _и_ от текущего неструктурированного people кажется достаточным обоснованием для по крайней мере компактного эксперимента -- другое дело, кто найдёт на него время. > Перенос (пересборка) пакетов на сизиф из кармана осуществляется > одной командой task merge. В этом случае все пакеты из кармана > собираются на сизифе в том порядке, в котором они были собраны > в кармане (в случае, если в сизиф ещё не вброшена более новая > версия, естественно). Здесь может быть казус, если эта новая версия что-то сломала в кармане, но IMHO вполне обрабатывабельно как exception: ну не собрался перед мержем на Sisyphus+pocket, ну просигналили и пусть люди думают, у них это по крайней мере получается. > Т.е. - по сути - это не карманы, а варианты а-ля гитовых? > бранчей для кусочка репозитория. Такой продвинутый вариант дедала. fine-grained. Кстати, да -- у нас сейчас получается CVS со всеми прелестями merge conflict'ов и HEAD, выданным на откуп сотне с лишним коммиттеров (вместо release engineer aka keeper), а предлагается git с topic branch'ами, которые мержатся "когда готово", а не "побыстрее". > Ответы на вопросы "кто реализует" и "кто внедрит", > я, к сожалению - не знаю... Лёш, а ты бы взялся за код? Просто из всех уже желающих подобного в системы сборки только ты вникал, насколько понимаю (хотя viy@ и sin@ тоже подходили к снаряду, а я когда-то читал incominger-code, но это было давно и неправда). Требовать не могу, сам понимаешь, но спрашиваю -- загрузка-то по работе понятна. On Tue, Jun 16, 2009 at 03:30:05AM +0400, Alexey Gladkov wrote: > Я не верю, что столь очевидные примеры, не приходили тебе в голову. Вот и мне кажется, что роботы вызвали неоправданную эйфорию. Вплоть до перевеса в приоритете по ресурсам над людьми. > Многие сложные интерактивные (хотя бы) программы легче > отлаживать и притирать друг к другу не включая в HEAD сизифа. > Ибо эта работа требует времени и промежуточных результатов для > тестирования. _И_ в случае подсистем или того же fx+extensions -- координированной работы нескольких человек. On Tue, Jun 16, 2009 at 04:19:02AM +0400, Alexey Gladkov wrote: > > При этом ты выкладываешь сборки firefox в people и даёшь ни > > них ссылки. > Именно. Но в эти репозитории не могут собирать другие > и перекладывать пакеты из них в сизиф неудобно. И следить за ними -- тоже. > > Вопрос в том, "карманы" какой формы подойдут тебе и > > пользователям пакетов, которые ты собираешь, больше, чем > > репозитории в people. > То что подойдёт всем уже выясняется некоторое время во многих тредах. При этом один из основных вопросов -- вообще есть желание слышать или нет. Потому как можно хором убеждать, что нужно, но не убедить. On Tue, Jun 16, 2009 at 04:15:00AM +0400, Evgeny Sinelnikov wrote: > > Есть другие соображения на эту тему? > Кроме того, текущая модель, не даёт возможности делать "мягкие" > bootstrap'ы. Сейчас это всегда волевое решение. Угу, причём и для простых случаев вроде смены soname мороки получается многовато. > - средство для оценки и самооценки результатов сборок новичков. > Дело в том, что ни один новичок с ходу, скорее всего, не > придумает куда ему выкладывать свои предварительные наработки. > Таким образом он вынужден долго топтаться на месте, вместо того > чтобы получить грамотную оценку своих результатов у коллег из > Team. Мало того, как смотреть в глаза интересным людям в community@ и sisyphus@, которых приглашаешь сюда, а здесь им презрительно кидают "неудачник"? Действительно, идея at@ про peer review технически более удобореализуема при помощи обособленных репо без того, чтобы "позориться" в сизифе. > - возможность конкуренции и параллельных сборок в команде не > приводящая к конфликтам, а позволяющая вести технические споры > на техническом поле. Это одно из главных; удивлён, что Дима не заметил(?) письма ab@: http://lists.altlinux.org/pipermail/sisyphus/2009-May/339495.html > И да... всё это можно делать отдельно на своей какой-то базе... > Но от этого, мне кажется пропадает какое-то единство при работе > в команде... Я ведь могу попытаться сделать описанное и на > git.etersoft.ru. Но вы ведь сами понимаете, что это будет > маргинальный ресурс. Ну этого как раз не стоит бояться, alt.linux.kiev.ua тоже был некоторое время маргинальным ресурсом, как и некоторые рассылки на lists.osdn.org.ua. Главное, хоть что-то пригодилось и пошло дальше (sisyphus.ru, sysadmins@). On Tue, Jun 16, 2009 at 07:37:23AM +0400, Денис Смирнов wrote: > DVL> Я на данный момент не вижу, в чём заключается значимое преимущество > DVL> централизованных "карманов" для предварительного тестирования, о которых > DVL> так много говорят последнее время, над распределёнными "карманами", которые > DVL> каждый может устроить где угодно при наличии соответствующих ресурсов. > DVL> Могу лишь предположить: > 1. Затраты времени на создание этих распределенных карманов. То > есть это означает необходимость каждому поднимать у себя girar, Даже если не каждому, а сделать стопку таких точек -- я не очень себе представляю авторизацию на них без ещё одного кусочка инфраструктуры вроде ldap.altlinux.org с публичными ключами. > DVL> - доступность (централизованная сборка в среднем более доступна всем > DVL> заинтересованным); > Не каждый вообще имеет ресурсы для того чтобы что-то куда-то > удобно выкладывать. Скажем у меня есть свой сервер на площадке, > однако у меня пока не было времени развернуть там аналог > git.alt, да еще и прикрутить туда pocket'ы. Хотя ты бы тоже скорее всего согласился предоставить часть его ресурсов, поскольку это было озвучено как один из важных вопросов? > DVL> - интеграция (централизованный "карман" теоретически должно быть немного > DVL> легче интегрировать в "материнский" репозиторий); > Это является наиболее существенным преимуществом. Поясню -- > использоваине pocket'ов само по себе это дополнительное > усложнение workflow разработки. Необязательно, если не отменяется и текущий путь. Например, не вижу смысла усложнять попадание в сизиф "листьев", от которых ничто не зависит по сборке и в рантайме, в случае несущественных изменений и уверенности сборщика в достаточности своей проверки. Вот доберусь обновить man-pages-uk -- так главная проблема с кодировками будет сразу видна, и покеты не нужны, потому как в любом разе некритично. > И если они хорошо интегрированы в git.alt, то будут причины > _сначала_ собирать в pocket для тестирования, и в последующем > выполнять перенос. Как минимум было бы важно чтобы этот > workflow использовался для критичных подсистем -- kernel, xorg. Угу. > Да и alterator'у бы не помешал. alterator/installer -- другое, тут нет внешнего фактора в виде апстрима и вопрос исключительно в удобстве координации между собой, когда надо подтянуть стопку разного и хорошо бы выложить в сизиф одновременно. > > На данный момент мне эти преимущества не кажутся значимыми. Ну а мне преимущества git.alt не кажутся значимыми. Серьёзно, SCM-то можно и локально использовать, а трафик нонче не проблема. Собственно, потому я этими преимуществами и пользуюсь от случая к случаю, а не постоянно и исключительно. > > Грубо говоря, я не вижу, каким образом появления > > централизованных "карманов" заметно повысит качество > > предварительного ручного тестирования. Дим, ты когда-нибудь что-нибудь из people помогал тестировать? > > Есть другие соображения на эту тему? > Несмотря на разговоры о карманах в течении нескольких _лет_ я > пока ни у кого не видел собственной инфраструктуры карманов, > которую бы он использовал для публикации. Таким образом есть > основания считать что без появления карманов на git.alt эта > технология использоваться на практике не будет. У нас. Повторюсь, в мире и это уже нашло применение, пока у нас опять всё продумано и на том и встало. Мне вот в 2005 было досадно, что в Ubuntu очень много _сделали_ продуманного гораздо раньше у нас по части инфраструктуры той же. Хотя не думаю, что они позаимствовали идеи -- просто уже витало. > Однако тот факт что некоторые пакеты необходимо публиковать > до отправки в Сизиф, как мне кажется, очевиден. Да вот да. Но почему-то не всем. Сам не пойму, почему, но не думаю, что из вредности. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/