From owner-cvs-ports@FreeBSD.ORG Mon Apr 4 03:59:46 2011 Return-Path: Delivered-To: cvs-ports@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id ED1F3106566B; Mon, 4 Apr 2011 03:59:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8F7D814E512; Mon, 4 Apr 2011 03:59:46 +0000 (UTC) Message-ID: <4D994232.30106@FreeBSD.org> Date: Sun, 03 Apr 2011 20:59:46 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sahil Tandon References: <201104021205.p32C5Y8g082718@repoman.freebsd.org> <20110402155230.GA80090@magic.hamla.org> <4D978D14.406@FreeBSD.org> <20110403055703.GA81066@magic.hamla.org> <4D98DAF1.5080802@FreeBSD.org> <20110403204922.GA81840@magic.hamla.org> In-Reply-To: <20110403204922.GA81840@magic.hamla.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dirk Meyer , cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/graphics/netpbm Makefile X-BeenThere: cvs-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 03:59:47 -0000 On 04/03/2011 13:49, Sahil Tandon wrote: > On Sun, 2011-04-03 at 13:39:13 -0700, Doug Barton wrote: > >> On 4/2/2011 10:57 PM, Sahil Tandon wrote: >>> I share your rationale for the most part, but I am still unclear about >>> what some might call an 'edge' case. >> >> It sounds to me like what you want are clear, bright lines that we >> can form policy around. I wish you luck with that. :) > > That is not what I want, but I do not fault you for jumping to that > reasonable conclusion. Fair enough. Meanwhile it's almost always infinitely easier to get what you want if you ask for it. :) >> Meanwhile, given the way that our ports and packages work bumping >> PORTREVISION is a blunt tool, and has tradeoffs. IMO ports >> committers need to have some firm guidelines for the common cases, >> but also to use their discretion on the edges. > > That is all fine and well, but given the nature of these issues, threads > similar to this one are unavoidable. I think you're right about that. What I'm not sure about is whether you think that's a problem. > People will always have questions > about why in case X, a bump wasn't issued while it was in a strikingly > similar case Y. And unless there is sufficient discussion of rationale > in the commit logs, I think that is OK. I think it's Ok even if there IS adequate justification in the logs. :) We have an influx of new committers, and those who wish to be, so periodically re-visiting these topics is useful. > It is not about bright lines or > other metaphors, but rather just a desire to understand what motivated a > bump in one circumstance but not another. So *now* it sounds like you're asking for better commit logs, which is something we definitely agree on. :) What I learned was that commit logs should be about 1/3 "what" (since you can get the full picture from the diff if needed) and 2/3 "why." Keeping in mind that the logs need to be understood years from now when we're all long gone is always a good thing too. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/