Re: Turnaround time for accepting new ports?

On Aug 10, 2006, at 8:06 PM, Mark Duling wrote:

> I think new ports should get a priority because, among other  
> reasons, when
> people put in the effort to make a port they do it for a reason and  
> it is
> just a big disappointment if they set out there for awhile as they  
> often
> do.  If no one else does first I'll take a look at your ports this  
> weekend
> and commit them if I think I'm competent to do them.

I totally agree (and this isn't the first time someone has had the  
same complaint).  New port submissions should enter the system in a  
different way.

Back when kvv was working on "Remote Index", we actually conceived of  
a very different system for organizing ports, one which actually  
wouldn't be all that difficult to implement.  Essentially, the notion  
was that where we use dports/PortIndex and the various dports/$ 
{category}/${name}/Portfile files today in locating and building  
stuff, we'd actually consult two locations along a search path:

1. The remote port index (stored somewhere on the central macports  
server).
2. The local port index, assuming the port couldn't be found in the  
remote index or the remote index was unavailable.

The remote port index would have, broadly speaking, two "buckets" for  
the associated Portfiles to live in.  Non-validated ports, namely  
ports that people had done and submitted (via a "port submit" command  
run against a submission directory), would be accessible to everyone  
in the "use entirely at your own risk" category.   Validated ports  
would be ports in the second bucket, that is to say those ports which  
had been tested and signed-off on by one of the anointed MacPorts  
committers.  It would be possible for a port user to choose to use  
ports only from the 2nd bucket, or to pick and choose ports from the  
1st only after looking them over first.  One also assumes there would  
be some sort of "port checkout" command for fetching the entire port  
recipe over as opposed to having it simply happen transparently as  
part of a "port install".

The local port index would continue to be the dports/ directory it is  
today.

That would make the whole notion of port submission a lot easier, and  
completely decoupled from any sort of version control scheme.  If the  
back-end server for "validated ports" ended up fetching things on  
demand out of a subversion repository then that would also be fine,  
but the average user would no longer have to know or care about the  
actual collection of files comprising the ports collection; it would  
simply be the equivalent of a remote database as far as they were  
concerned.

- Jordan