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 B7F221381F3 for ; Tue, 23 Apr 2013 19:25:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E0C2E0A70; Tue, 23 Apr 2013 19:25:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4E108E09D2 for ; Tue, 23 Apr 2013 19:25:42 +0000 (UTC) Received: from [192.168.1.122] (bas1-ottawa09-2925289052.dsl.bell.ca [174.92.94.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 21F6333DD6D for ; Tue, 23 Apr 2013 19:25:41 +0000 (UTC) Message-ID: <5176E02D.8050302@gentoo.org> Date: Tue, 23 Apr 2013 15:25:33 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask References: <20130419091632.D01152171D@flycatcher.gentoo.org> <20130419153043.30ffc50c@portable> <20130421170549.41cfea49@portable> <20130422154033.65a68a40@portable> <20130423200053.77ed8b49@marga.jer-c2.orkz.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: a9c92bad-46f1-42e9-90f4-d8a3ee688c9f X-Archives-Hash: e3cc860bd8e14a2cb8a4fca2c5b13f0c -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/04/13 03:11 PM, Rich Freeman wrote: > On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner > wrote: >> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman >> wrote: >>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers >>> wrote: >>>> Er, you can't be seriously suggesting we will drop repoman >>>> checks with the migration to git? I don't see how that would >>>> benefit anyone. >>>> >>> >>> Interesting point. One thing to keep in mind with git is that >>> commits don't affect the "central repository." Pushes are what >>> impacts the repository. >>> >>> If I spend six months working on a bunch of coordinated >>> package changes, nobody will see a thing until I push those >>> commits and 500 ebuilds all change atomically (not that I'm >>> suggesting that lack of communication is to be encouraged). A >>> repoman check on a commit may not reflect its impact six months >>> later when it actually hits the main tree. >> >> ... if you're squashing 6 months of work into a single commit >> before pushing. >> >> I don't think we want to do that, do we? Maybe bisecting isn't >> particularly interesting for the portage tree. > > I never said that I was squashing 6 months of work into a single > commit, only that I was pushing 6 months worth of commits in a > single operation. > > Any repoman checks done at the time of each commit are essentially > worthless. Consider this example: > > 1. Create app-misc/foo-1.2 which depends on app-misc/bar. > Repoman checks this and it is fine. 2. Do 500 other commits. 3. > Push it all to the tree six months later. 4. Get bug report that > app-misc/bar was renamed two months back. > > Repoman is about checking changes to the main repository. What > matters isn't how the change you made impacts your clone of the > repository, but how that change impacts the main repository when > it eventually makes its way back. > > Unless your workflow is to pull, commit, and push with no > intervening commits by other contributors, the repoman check needs > to be done before the push, not the commit. > > Rich > This makes a lot of sense to me too -- repoman checks that are absolutely -needed- are those run at push time, specifically when pushing to master. 'git commit' time doesn't have an equivalent in cvs, but to me the checks that should be done at this time would be covered by the 'repoman -d full' checks we're already supposed to do, and I don't think those need to be enforced. 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.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlF24C0ACgkQ2ugaI38ACPASUQD/VqYe+f28wPGByWjcCicWiF5e 84vjyyrMxS3IF1qLeisA/jzfePn7pID8RsUqLYUtdSF+xo6dZDhLJgQARelS4yMx =bywE -----END PGP SIGNATURE-----