[CFT+BRAINSTORM] One USE_ to rule them all

['Baptiste Daroussin']

On Tue, Feb 12, 2013 at 04:13:19PM +1100, Dewayne Geraghty wrote:
> > -----Original Message-----
> > From: owner-freebsd-ports at freebsd.org 
> > [mailto:owner-freebsd-ports at freebsd.org] On Behalf Of 
> > 'Baptiste Daroussin'
> > Sent: Tuesday, 12 February 2013 1:36 AM
> > To: Dewayne Geraghty
> > Cc: ports at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130212/7c4c6cd2/attachment.sig>