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=unavailable version=3.2.5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1403178789; bh=g0wclGzM0vPBbMqBXCbWV02Zvwra2WNG0gnRIylzHB0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=s7TyCm5EwLlAvfrvsXkMQItUltXeSJco6MmwLwsHul/m9jD5KNTpT8x0LrFFqUDJ9 MvbzSiKZ5K4uM1hsn7kg8LACHerFn3KuUMQHRcwZeqOhgp8ff3Wnjarnx8iibVOp5Y E+lW0LO09ppXOADFHXj0xdcSFEwPWuAddKDb0Q6Q= 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=1403178785; bh=g0wclGzM0vPBbMqBXCbWV02Zvwra2WNG0gnRIylzHB0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=f7ji0gEchW8ruHgom6p3K6m7ZNqvN0/WzVSUJrP8rQp+tE9JaspEFTgL/V6jEFdYi HPda3LGn+CbVJzaBnPcAVqROccS8LI11BmBqIJnkMt7XveR9GhfNuHQ8Z1qiYDWVg6 holUVZiguPtOSi/65Nk0nAhjOlpQRPB0ZFBunreY= Date: Thu, 19 Jun 2014 14:55:41 +0300 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20140619115541.GA10395@dad.imath.kiev.ua> References: <20140617194200.GA27630@dad.imath.kiev.ua> <20140619075237.GA9295@dad.imath.kiev.ua> <20140619110814.GA10173@dad.imath.kiev.ua> <53A2C53F.7080504@altlinux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53A2C53F.7080504@altlinux.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Anton Farygin Subject: Re: [devel] =?utf-8?b?R2VhciDQuCDQstC90LXRiNC90LjQtSAgICBWQ1Mu?= 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: Thu, 19 Jun 2014 11:53:37 -0000 Archived-At: List-Archive: List-Post: On Thu, Jun 19, 2014 at 03:10:55PM +0400, Anton Farygin wrote: > On 19.06.2014 15:08, Igor Vlasenko wrote: > >Соответственно, когда такие утилиты будут готовы, > >надо будет просить всех майнтайнеров, использующих > >VCS - обновляемые gear репозитории, создать и опубликовать > >в этих репозиториях .gear/upstream/remotes, > >а если есть желание ограничить доступ к своему репозиторию, > >то делать это с помощью acl, а не сокрытием его служебной > >информации. > > я в соседнем письме написал, почему нет смысла использовать для > этого .gear/upstream/remotes > т.е. - я не хотел бы использовать инструмент, который будет мне > предоставлять алгоритм работы другого ментейнра. > например, мне привычнее upstream remote держать в бранче не > upstream, а source. > > Как тут быть ? Легко :) 2 файла .gear/upstream/tag-filter и .gear/upstream/remotes - это формат, в котором будет храниться служебная информация, которая будет необходима для watch по tag. При этом .gear/upstream/remotes имеет более глубокий смысл - * он позволяет сделать информацию о remotes публичной, * может использоваться независимо от того, нужен ли watch по tag, * крайне нужен NMUшникам. Но из этого совершенно не следует, что если пакет foo одновременно сопровождает 2 майнтайнера A и B, то если один из них создал .gear/upstream/remotes, (например, А), то второй (В) отгребет из этого файла не нужные ему ветви. Ведь никто не заставляет выполнять у себя gear-restore-remotes, и робот тоже не будет этого делать. Я в позапрошлом письме рассматривал алгоритм обновления. Если в gear/rules тег, как в tar:v@version@: . то там достаточно использовать временную служебную ветвь, какой-нибудь gearobersturmbannbranch. Однако, служебная ветвь -- это мусор в репозитории, поэтому умный робот проверит, есть ли в .git/config ветви, описанные в .gear/upstream/remotes, если есть, будет использовать их, чтобы не мусорить, если же нет, создаст свой gearobersturmbannbranch. Если майнтайнер B тоже не хочет, чтобы у него создавался gearobersturmbannbranch, а использовались его собственные, отличные от майнтайнера A названия ветвей, он может добавить файл .gear/upstream/remotes.$USER, который будет иметь приоритет перед .gear/upstream/remotes. А еще можно export GEAR_UPSTREAM_REMOTES_SUFFIX=..smth.., и перекрыть все с помощью .gear/upstream/remotes.$GEAR_UPSTREAM_REMOTES_SUFFIX если вдруг понадобится. Конечно, в gear/rules архив может создаваться не по тегу, а по ветви: tar:upstream: . но тогда от создания у себя ветви upstream никуда не деться, против лома нет приема, она железобетонно прописана в gear/rules, разве что форкать свои .gear/rules. Так хорошо? -- I V