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 6201313838B for ; Sat, 4 Oct 2014 00:00:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CA66E088B; Sat, 4 Oct 2014 00:00:26 +0000 (UTC) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 92BFCE0886; Sat, 4 Oct 2014 00:00:25 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hy10so1357746vcb.1 for ; Fri, 03 Oct 2014 17:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QG3JwVHCrvvquTGn+zdupNQu4X/fqNf1/QM/JdkqB3M=; b=Ma+78wVbuaQx/eTuGNGjjJ1KGuI/sWHIE65ZRF4cahO39voYzsB6mVCv8Tmoa6WuQd ZUFKytXG3+xx8cu8GpweHes/uRDhrYwb+vonxy6DdVUfLFrIAhxE//dqz0/XCe6Pv7bo qhfa8mONcLyV25vqmIXSkGQJVaI3C/Znomf77uCosztwj+U6lHlVXlLFgXFNfAyzBZql SHg7oL67Te9nIJz66AwWkip+T2AE6RFQmJX+YGlPjLIypG2zZ4VIrBOGdzTsT8ofqXBV OprlZ7oNFyrunr/JLQ+WeCJDmBKNKyhcvUUfXi1vsoVyh5Bcd54YBzxmRSNGKgIGSbhJ DorA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.220.112.200 with SMTP id x8mr6389956vcp.11.1412380824676; Fri, 03 Oct 2014 17:00:24 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Fri, 3 Oct 2014 17:00:24 -0700 (PDT) Date: Fri, 3 Oct 2014 20:00:24 -0400 X-Google-Sender-Auth: DrLD0m7QM7Tb5o2L5XyGEsfhI6Q Message-ID: Subject: [gentoo-project] Council / Git Migration Agenda From: Rich Freeman To: gentoo-project@lists.gentoo.org, gentoo-scm@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4c2c94a0-e970-4e94-86ff-84548596bb5d X-Archives-Hash: b02fec373f1d8d9b7ca18ac34ca1bd4a Starting a new thread for discussion: On Thu, Oct 2, 2014 at 7:06 PM, Micha=C5=82 G=C3=B3rny = wrote: > Dnia 2014-10-01, o godz. 13:30:55 > Rich Freeman napisa=C5=82(a): > >> On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman wrote: >> > If you'd like to contribute another agenda item, please reply to this = email. >> >> I'll offer up a further topic for the git migration. > > I think that there are a few issues that the Council may actually want > to discuss. I was thinking of an additional item also worth consideration. So far the general plan has tended to be that we would do a full historical git migration, and the last commit would just be the active tree, which would then be further cleaned up (remove cvs headers, changelogs, switch to thin manifests, etc). I was thinking that it might make more sense to just make things really simple and ONLY migrate the active tree into the starting git repository. That is, basically take the rsync tree, remove metadata, and do a git init. (Then follow that up with removing changelogs, cleaning up cvs headers, and so on.) A historical migration could be done in parallel and released a few hours later. However, it would not be a contiguous repository. That is, the converted active tree commit would not have any parents. If you wanted to have a contiguous tree you would need to splice in the historical migration with git replace. Rationale: 1. The historical git migration right now is not perfect. It probably will never be perfect, and there is debatable value in even trying to make it perfect. 2. Somebody may very well want to improve on the historical git migration. If the converted repository doesn't favor any particular historical migration, then anybody can swap in the historical migration of their choosing. We aren't locked into a point-in-time migration that isn't the best that it could be. Anybody who wants a better migrated history can make their own. 3. I fear that some are going to argue that we shouldn't do the migration until the historical migration is better than it is now. Just how much better it needs to be could be a matter of considerable debate. Not making a permanent connection between the historical and active migration sidesteps this debate. 4. Decoupling the historical and active migration makes the active migration brain-dead simple. Downtime will be minimized, and we don't have the possibility of running into some issue hours into a migration where we need to try to figure out how to handle it. The active tree will migrate and cut over as quickly as things can be swapped out. The historical migrated tree will be posted whenever it is ready - likely within hours but if it takes longer there really is no big loss. We can fix it as many times as we like. 5. In general I think that we're well past the point of diminishing returns. I personally don't see any return on improving the historical git tree beyond the general fun of tinkering with the code. In the meantime many are eager to see the active tree migrate. Let's stop holding up moving forward by obsessing about looking backwards. -- Rich