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 2292E1381F3 for ; Tue, 23 Apr 2013 19:43:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4A358E09DE; Tue, 23 Apr 2013 19:43:30 +0000 (UTC) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 48DB0E099E for ; Tue, 23 Apr 2013 19:43:29 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ha11so1058469vcb.30 for ; Tue, 23 Apr 2013 12:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=q36ISDmWFe3D3Vk92hLY7RzE9cTET3gWdWmcdBH/f1Q=; b=AKgRwkZV3DrsiopaU5I781zrkgebx6daqULL7b9zJrwrLAifdMorkWqRuZpHurug7a C2y6h5tMjKLXPUSVXMICciL0+Wc3jJJ+4FQAJv5WQCjyfHbNYlshzU4/VvsBEBTJSGJE I8FtPL4wZB+NiZBP5uFH+K8KY4xZcSjkm3kTw2MXRiHj805fwt3DcSrd/5NLJlkf3oeF /vyvHUR1HbpYtZqBrU2OIa+qDGm5FuR/REsWhvnn3o5Unqa5IIQRSqxntr/tJG6aukFv UaADAZW4fOYX9s9KxwD5RXoWXp+fWno2r5t+BawIsfsg3aJHHU8MXfrN+8iI+SzFkW+2 a0tA== 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 X-Received: by 10.52.88.2 with SMTP id bc2mr4731271vdb.27.1366746208465; Tue, 23 Apr 2013 12:43:28 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.168.4 with HTTP; Tue, 23 Apr 2013 12:43:28 -0700 (PDT) In-Reply-To: <5176E02D.8050302@gentoo.org> References: <20130419091632.D01152171D@flycatcher.gentoo.org> <20130419153043.30ffc50c@portable> <20130421170549.41cfea49@portable> <20130422154033.65a68a40@portable> <20130423200053.77ed8b49@marga.jer-c2.orkz.net> <5176E02D.8050302@gentoo.org> Date: Tue, 23 Apr 2013 15:43:28 -0400 X-Google-Sender-Auth: 2dQ9C1xXvHFY_wmvHm6Zj8nDKbw Message-ID: Subject: Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 3e1c38bc-8fef-4ed3-8cee-a6ae4275ff47 X-Archives-Hash: 0ad122a9df0bf941197752e75691df8d On Tue, Apr 23, 2013 at 3:25 PM, Ian Stakenvicius wrote: > Alternatively, we could enforce repoman checks on any commit or push > operation in master, and leave branches to their own devices. Of > course, I haven't seen (or looked for, tbh) how tree development will > be implemented/suggested to be done in git so I've no idea what role > branches might play.. Keep in mind that the following are all roughly equivalent in the world of git: 1. The master branch on anything other than the copy of the repository hosted by infra. 2. Some other named branch anywhere. 3. An overlay. Just because you're committing to master doesn't mean that anybody will ever see it. As far as how things will go - this seems very much TBD. There have been various random thoughts on this list, and in IRC discussions. My two cents: 1. For most routine work, just do it all in master, rebasing commits, so that in the end it looks just like the current CVS (well, assuming CVS had cross-file atomic commits). 2. For big projects, do the work in an overlay first. Then for staging purposes consider a short-term branch in the main repository with frequent rebasing during any QA checks, then do one big fast-forward-merge at the end. That lets you do big atomic tree-wide changes without blocking commits, and having the final merge in a single commit (think KDE stabilization, big eclass changes, etc). We already have overlays, so I'm not sure we want to end up with lots of long-term branches in the main portage repository. All of this is of course talking about the portage tree. More traditional software development projects like portage (the software), eudev, etc should of course use more traditional use of git. Rich