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=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.2.5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1403045800; bh=BSLXxVmpmsKExSiZpv5TQ8w57jQe6RswK0zVIGIxD5w=; h=Date:From:To:Cc:Subject; b=Md9ig6ukamVurwliEPKaP9rUyVt0FGfN1Mu3+Gi6pSiT/4pNTw1CjPAk48oPaM9/o YSYf5FWGCptVtZqE1IFZ3I/jsauWYUSB66EXO7KraeHDvRne/xBh/leF+S4Pqd8YrR EhkO2svo1upDRPA250hkhchoA2QkZaJ4o/V8+aLo= X-Virus-Scanned: amavisd-new at imath.kiev.ua DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1403045796; bh=BSLXxVmpmsKExSiZpv5TQ8w57jQe6RswK0zVIGIxD5w=; h=Date:From:To:Cc:Subject; b=X0DzGfKz1n9bHAwAHCtiwsA4O1kXNyB1uwRedltO/oEek2Yvc6MOmh5RHMNpT1JTy P6L+8UalRWwWVQw6D+hv3tPOddb22bvXQouVE/gbu9z0kawmQdRmGto3RQ3Vg6arcK BrF2XaptKxdOLfs5VZFuQNEB+RR6qK0UOaJEhEew= Date: Wed, 18 Jun 2014 01:59:05 +0300 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20140617225903.GA27933@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Anton Farygin Subject: [devel] =?utf-8?b?R2VhciDQuCDQstC90LXRiNC90LjQtSBWQ1Mu?= 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, 17 Jun 2014 22:56:50 -0000 Archived-At: List-Archive: List-Post: Господа, переношу вопросы автоматизации работы с gear репозиториями, которые обновляются из удаленнного VCS, в отдельную тему. Здесь хотел бы обсудить, какие утилиты должны быть добавлены извне к gear и какие изменения должны быть в самом gear сделаны, чтобы сделать совместную работу с gear репозиториями, которые обновляются из удаленнного VCS, 1) удобной для стороннего человека 2) удобной для робота. Постараюсь на примерах обрисовать проблему и то, как должно выглядеть ее решение. Итак, представим себя в роли члена qa@. Все майнтайнеры на море, а в это время как раз обнаружена страшная увязвимость headbleed. Апстримы оперативно выпустили исправления, майнтайнеров нет, и нужно вместо них обновить их пакеты, абсолютно чужие, т.е. их gear репозиторий будем видеть в первый раз. Что должно быть: клонируем с git.alt: последнюю собранную версию. запускаем волшебную команду gear-fetch. волшебная команда gear-fetch (в gear) * выкачивает обновление через git (и в идеале, может и git-svn) над ней может быть моя волшебная надстройка (сакжем, gear-vcs-update), которая * (опционально) расставляет при необходимости теги в формате, который вписан в .gear/rules (например, v@version@). * (опционально) мержит обновления в ветки с патчами и в master, вносит изменения в spec. qa-инженеру остатется только просмотреть изменения и отправить пакет в Сизиф. но и без волшебной надстройки после gear-fetch все тривиально: руками мержим, руками add_changelog и послали в Сизиф. Таперь приземлимся и посмотрим, на что, что есть. клонируем репозиторий с git.alt и пытаемся руками проэмулировать волшебную команду gear-fetch, поскольку она еще не существует. и здесь нас ждет ряд засад. забудем о git-svn, то сплошной ужас. для простоты пусть будет git. хотим сделать git fetch. Засада1. А откуда? Эта информация есть локально у майнтайнера, но у нас она утеряна -- в нашем клоне репозитория информации о его remotes нет. Майнтайнер в отпуске на море, слишком далеко, чтобы использовать телепатию. Пока роемся по сайтам, приходим к выводу, что в репозитории нужна запись, откуда делать git fetch. И эта запись должна быть понятной для утилит. к примеру, запись в спеке # VCS: ... может помочь для репозитория Андрея, а в остальных 9 из 10 случаев означает только, что пакет был основан на Fedor'овском пакете. Возможно, роботом дернут, возможно, руками взят. Т.е. нужен файл в недрах .gear, .gear/upstream/откуда. далее, * Засада2 *. Узнали <Где>, можем написать git getch <Где>. но что брать? git getch <Где> <что>. Есть commit с исправлениями. и в master, и cherry-pick'ed в ветвях. Пока думаем и гадаем, приходим к выводу, что нужна запись в недрах .gear, .gear/upstream[что]. Альтернативно, можно подождать месяц, когда будет <релиз>, а с ним <тег>, на который можно будет ориентироваться вместо удаленного бранча. И тут же плавно проваливаемся в *Засаду 3*. * Засада3 *. куда? напомню, полная команда имеет вид git fetch <Где> <что>:<куда> > IV>> поэтому желательно иметь указание, в какие ветви что куда должно идти. > AF> честно говоря не понял, зачем это ? вижу всё так-же как и в случае с > тарболлом и исходниками в отдельном бранче. Ну совсем никакой разницы > -просто вместо gear update будет git pull. остальные этапы точно такие-же. Для некоторых репозиториев действительно прокатит, назвать ее как-то устрашающе gearobersturmbannbranch и сделать fetch в branch gearobersturmbannbranch: git fetch <Где> <что>:gearobersturmbannbranch но, во первых, не все .gear/rules основаны на tags, к примеру, в virt-viewer $ cat virt-viewer.git/.gear/rules tar: upstream:. и волшебная команда gear-fetch должна поддерживать и такие rules. Во вторых, для NMU с одноразовым репозиторием это еще прокатит, сделали NMU, а репозиторий выбросили. Но волшебная команда gear-fetch должна быть в первую очередь удобна для основного майнтайнера. У него и так есть волшебная команда git fetch origin, основанная на тайном знании remotes. Если там записано, что fetch делается в ветку upstream, то он делается в ветку upstream. Приходим к выводу, что нужна запись в недрах .gear, .gear/upstream[куда]. С ней волшебная команда gear-fetch отработает точно так, как git fetch origin. Иначе она просто намусорит: за ней придется прибрать руками, ветку upstream передвинуть руками, мусор gearobersturmbannbranch удалить. далее, ветка(ветки), записанные в .gear/upstream[куда], должн(ы) отражаться и в .gear/tags. т.е. gear-update-tag должна поддерживать .gear/upstream[куда], т.е. записывать в .gear/tags/list текущие позиции этих ветвей, чтобы их можно было восстановить, просто склонировав репозиторий с git.alt и запустив волшебную команду gear-fetch. Так я представляю функциональность базовой волшебной команды gear-fetch. Функциональность волшебных надстроек над gear-fetch можно будет обсудить позже, обсуждение лучше начать с базовых вещей. -- I V