Date: Tue, 12 Feb 2013 16:13:19 +1100 From: "Dewayne Geraghty" <dewayne.geraghty@heuristicsystems.com.au> To: "'Baptiste Daroussin'" <bapt@freebsd.org> Cc: ports@freebsd.org Subject: RE: [CFT+BRAINSTORM] One USE_ to rule them all Message-ID: <22320519B33A4AB9AB68DC7C4BB84765@white> In-Reply-To: <20130211143553.GA4326@ithaqua.etoilebsd.net> References: <20130204181946.GF67687@ithaqua.etoilebsd.net> <77AC0D5229B747E1B7A7171E84BB8C7F@white> <20130211143553.GA4326@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----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_<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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22320519B33A4AB9AB68DC7C4BB84765>