From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1A0E3139694 for ; Tue, 25 Jul 2017 16:12:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 113271FC03F; Tue, 25 Jul 2017 16:12:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BB84F1FC007 for ; Tue, 25 Jul 2017 16:12:31 +0000 (UTC) Received: from [10.1.1.204] (vpn1.metro-data.com [65.213.236.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id A63C53417E0 for ; Tue, 25 Jul 2017 16:12:30 +0000 (UTC) Subject: Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow To: gentoo-dev@lists.gentoo.org References: <1500969906.1206.1.camel@gentoo.org> <0A428688-D128-4767-A9E5-E0F2D3004B18@gentoo.org> <5a155985-1ce4-9872-0259-b67520d9a867@gentoo.org> <1500988986.795.5.camel@gentoo.org> From: Michael Orlitzky Message-ID: Date: Tue, 25 Jul 2017 12:12:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 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 In-Reply-To: <1500988986.795.5.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Archives-Salt: e30f909d-825b-4513-b83f-ef6f94e5d620 X-Archives-Hash: c0a827cdc76588a4f42dc37c8fd5e81e On 07/25/2017 09:23 AM, Michał Górny wrote: > > How is that relevant? Revision bumps are merely a tool to encourage > 'automatic' rebuilds of packages during @world upgrade. I can't think of > a single use case where somebody would actually think it sane to > checkout one commit after another, and run @world upgrade in the middle > of it. > Revisions are to indicate that one incarnation of a package differs from another in a way that the user or package manager might care about. And on principal, it's no business of yours what people want to do with their tree. If someone wants to check out successive commits and emerge @world, he's within his rights to do so. This is relevant because your proposed policy, * presumes to know how people will use the tree, and places arbitrary restrictions on them * can cause problems if those assumptions don't hold * requires developers to think about when it's safe to push (Did I push those changes last night? Do I need another revision?) * and is more complicated than the safe solution, anyway Here's my proposal regarding revisions: If you make a commit that requires a revision, make a revision. If you wind up with an -r15 in the tree, who cares? It's simpler, safer, and less to think about.