On Tue, Feb 12, 2013 at 04:13:19PM +1100, Dewayne Geraghty wrote: > > -----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 don't get what you expect here, do you have an example? > > 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. Well the long term plan has been mentionned in the first mail, it is to slowly get rid of the large and complex bsd.*.mk as much as possible to favour to the new load-on-demand features, only loading and parsing what is needed might help a lot improving the speed of the make(1) operations in the ports tree. > > 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. Yep and most of the time nothing of that case would be necessary it will be seemless, in fact for now I can't see something that won't be seemless, but sure if one happen then there will be scripts/exp-runs everything need to get the migration as smooth and seemless as possible. > > 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: We might give blanket to committers to change the ports to use features (with a kind heads up to the maintainer of course) to help speeding up the migration. > 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? Like optionsng but more except for probably touch ones (I don't have one in mind yet :)) > 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? The migration should have no effect on users as a new feature can only hit the tree if there is a migration path with compatibility. And given that features are not as exposed to users as options framework can be, most users may not even notice :) > 3. When will the change activity commence? As soon I have finished my exp-run on with the first features (gmake, iconv and motif might be the first one) > > 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. Thank you. regards, Bapt
pgpAD07wKWXMt.pgp
Description: PGP signature