From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 23306138A1F for ; Sun, 14 Sep 2014 15:30:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6C711E084F; Sun, 14 Sep 2014 15:30:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 57716E083D; Sun, 14 Sep 2014 15:30:52 +0000 (UTC) Received: from localhost.localnet (unknown [58.35.111.197]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id ECF803401B3; Sun, 14 Sep 2014 15:30:50 +0000 (UTC) From: Patrick Lauer To: Davide Pesavento Cc: gentoo-dev@lists.gentoo.org, gentoo-infrastructure@lists.gentoo.org, qa@gentoo.org, council@gentoo.org Subject: Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it) Date: Sun, 14 Sep 2014 23:30:36 +0800 Message-ID: <16601943.lz3Cz1dQbC@localhost> User-Agent: KMail/4.13 (Linux/3.16.0-gentoo; KDE/4.14.0; x86_64; ; ) In-Reply-To: References: <20140914140344.6c6b99e5@pomiot.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Archives-Salt: fd825b09-e08e-4ec1-8ef3-849f32efebbb X-Archives-Hash: ee774a4636b4e679dfd7a5fcb9f54d51 On Sunday 14 September 2014 15:40:06 Davide Pesavento wrote: > On Sun, Sep 14, 2014 at 2:03 PM, Micha=C5=82 G=C3=B3rny wrote: > > We have main developer repo where developers work & commit and are > > relatively happy. For every push into developer repo, automated mag= ic > > thingie merges stuff into user sync repo and updates the metadata c= ache > > there. >=20 > How long does the md5-cache regeneration process take? Are you sure i= t > will be able to keep up with the rate of pushes to the repo during > "peak hours"? If not, maybe we could use a time-based thing similar t= o > the current cvs->rsync synchronization. Best case only one package is affected - a few seconds Worst case someone touches an eclass like eutils, then it expands to so= mething=20 on the order of one or two CPU-hours. =20 > Are we going to disallow merge commits and ask devs to rebase local > changes in order to keep the history "clean"? Is that going to be sane with our commit frequency?