> -----Original Message----- > From: owner-freebsd-po...@freebsd.org > [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of > 'Baptiste Daroussin' > Sent: Tuesday, 12 February 2013 1:36 AM > To: Dewayne Geraghty > Cc: po...@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_<FEATURE>, 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. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
