Has the port collection become to large to handle.

[fbsd]

Comments have been posted about how to determine in a fair way 
which ports would be included in the most commonly used category?

The solution to that concern is pretty easy to do. 
Modify the master make code to post a count to a special 
purpose FreeBSD website by passing it a cookie.
Now every time a any user runs the port "make install" that
special purpose FreeBSD website will be accessed counting  
how many times that port is really executed. Then use that 
count per new release of FreeBSD to determine the ports that 
go into the commonly used category. The side benefit is this 
would also bring to light the dead and unused ports that can 
be removed from the ports collections or put in an unsupported 
category which would further help in controlling the size of 
the base collection. Of course some precautions in counting the
hits to the special purpose FreeBSD website would have to be used 
to drop attempts by people trying to manipulate the results in 
favor of some particular port.


The comments from one of the maintainers about the fact that 
the maintainers are not allowed to build the official 
packages is a policy that can easily be changed. 
Its more important to have timely packages available then 
the security of waiting for the mass package build done once 
per new FreeBSD version release. A warning comment in the 
maintainer built package informing the installer that this 
package was built by the maintainer and not by the secure 
mass package build process will give the installer the info 
he needs to decide if they want to use that version of the 
package or wait for the official secure built version. 
This also allows the maintainer to build different versions 
of the package for each different version of major dependents 
such as php4/5 apache1/2 mysql3/4/5 whatever.
The mass package build process does not allow this flexibility. 

The fact is the maintainer is all ready being trusted to 
manage the port so I see no reason NOT to trust him to 
create the matching package.

Even the need of the secure massive package built process is 
now questionable.
The resources and time needed for performing the 
secure massive package built must impact the release timeline of 
new FreeBSD releases. Doing away with it may streamline many 
other different internal release process.