From owner-freebsd-ports@FreeBSD.ORG Tue Feb 12 05:57:48 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6DD28F24; Tue, 12 Feb 2013 05:57:48 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id 8521C61A; Tue, 12 Feb 2013 05:57:47 +0000 (UTC) Received: from nschwcmgw07p ([61.9.190.167]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20130212051526.LLHY2821.nschwmtas05p.mx.bigpond.com@nschwcmgw07p>; Tue, 12 Feb 2013 05:15:26 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nschwcmgw07p with BigPond Outbound id zHFR1k00b5LKYmq01HFRdP; Tue, 12 Feb 2013 05:15:26 +0000 X-Authority-Analysis: v=2.0 cv=BKIxXSsG c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=KVj9CZslCdUA:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=MBwDIv9BvVQA:10 a=6I5d2MoRAAAA:8 a=wwmw74T1I3LbJhz8Ll0A:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r1C5DFaG004739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Feb 2013 16:13:15 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Baptiste Daroussin'" References: <20130204181946.GF67687@ithaqua.etoilebsd.net> <77AC0D5229B747E1B7A7171E84BB8C7F@white> <20130211143553.GA4326@ithaqua.etoilebsd.net> Subject: RE: [CFT+BRAINSTORM] One USE_ to rule them all Date: Tue, 12 Feb 2013 16:13:19 +1100 Message-ID: <22320519B33A4AB9AB68DC7C4BB84765@white> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20130211143553.GA4326@ithaqua.etoilebsd.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 thread-index: Ac4IZSQOWoqvLberSU2sQXQVT/+s0wAQLiAg Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 05:57:48 -0000 > -----Original Message----- > From: owner-freebsd-ports@freebsd.org > [mailto:owner-freebsd-ports@freebsd.org] On Behalf Of > 'Baptiste Daroussin' > Sent: Tuesday, 12 February 2013 1:36 AM > To: Dewayne Geraghty > Cc: ports@freebsd.org > Subject: Re: [CFT+BRAINSTORM] One USE_ to rule them all > > On Mon, Feb 11, 2013 at 09:21:47PM +1100, Dewayne Geraghty wrote: > [...] > > > > > > > Baptiste, > > The original question is a functional change to Mk/*, which seems > > beneficial. The specificity of USE_FEATURE is in keeping with the > > long term goal of "> The very long term goal will be to > switch as much > > code as > > > possible to be turn into a feature (when it makes sens of course)" > > > > A generic use of "USE" makes less clear for those > developers and users that are familiar and maintain > USE_${FEATURE} in their port. > > I appreciate the improvements that are being made, but > small steps are > > easier for the large numbers of people that are familiar > with the existing system. > > What is your suggestion, about the name of the macros, then? > concerning the small steps, that is the plan, convert things > small steps by small steps into features. > > > > > Also are their any foreseeable adverse side-effects of > making this change? > > Not that I know, and noone pointed me to an adverse side-effetcs yet. > > regards, > bapt > My suggestion regarding the name of the macros is to retain the original concept that you proposed, which is about centralising USE_, rather than change the name as well as centralising functionality. Moving the function of an existing name makes it clear what is changing; so please retain USE_$FEATURE. I think a collaborative expectation is a fair assumption. You'd mentioned a long-term plan, perhaps that is something that also needs to be shared, so folks can take in the big picture and consider the issues as a whole - which implies a well advertised review window. As a project that changes infrastructure, it goes without saying that breaking existing infrastructure should be avoided. We should be able to forsee the impact of change and provide scripts/src that make the migration smooth and seemless, possibly overlap functionality during a transitionary phase. After performing a cursory review and search for USE_$FEATURE under /usr/ports/security, where there are 89 unique instances of USE_$FEATURE from: grep USE_ /usr/ports/security/*/M* | cut -d: -f2 | cut -d= -f1 | grep ^USE_ |sort | uniq; It seems that there's going to be a lot of work by a lot of people, some requiring co-ordination. So, some questions about the process, rather than just the work: 1. How do you envision the change to occur - will the changes be collated and deployed in one hit, or staggered over a long period of time, like optionsNG? 2. Will or should the ports be frozen or snap-shotted in entirety to avoid maintenance effort by people that use ports, rather than maintain them? 3. When will the change activity commence? Baptiste, you have been prompt and enthusiastically helped people with issues with optionsNG; and I appreciate the improvement to our infrastructure that you've made. Kind regards, Dewayne.