Proposal for a new repository layout

[Jordan K. Hubbard]

On Apr 25, 2007, at 12:40 PM, Juan Manuel Palacios wrote:
The testing ports tree would just be a facility offered by the  
project to developers who, like you, develop new features in trunk  
and/or bug fixes and, naturally, want and need to test them in  
Portfiles. Such Portfiles break an MP installation based on released  
code as we've seen one too many times already, so we can't have them  
in the shipping ("released") ports tree as they are useless there.

See, maybe it's just me, but I'd really like to see an end to the  
distinctions being drawn here concerning "released" vs "testing"  
since I don't think that's the right place to draw the line.  What  
we're really talking about here, particularly in a possible future  
where something like James' mpwa (aka "Remote Index") is the way we  
do things, is "untested" and "vetted".  The process of vetting  
something is still TBD, but one assumes it would involve a lot more  
testing methodology than we currently have for releases and would  
actually have some validity.   You would also only vet individual  
portfiles (and, presumably, at least their dependencies), so the  
process of "releasing" stuff becomes very light-weight and does not  
require tying everything together in one big bundle just to get some  
notion of quality control around it.

Then we simply have base/, which is periodically tagged to indicate  
synchronization points for the developer-users of MacPorts (as  
opposed to core developers, who live on trunk and are the ones who  
decide when to lay down base tags) and one big pool of Portblobs in  
the remote database, each blob having the usual range of attributes  
to facilitate ease of search / categorization as well as the "vetted"  
and "untested" attributes.   If we have all of that, we no longer  
have to have releases, the whole notion of "a release" becoming  
essentially meaningless.  You just have user selection criteria and a  
system with enough metadata to make it possible for users to specify  
whatever criteria makes sense for them.

One more point:  I still think that people who are actually  
interested in base/ aren't really "users", they're "user-developers"  
as I described them earlier.   Actual users, which MacPorts has never  
had at any point in its history, care only about packaged software  
and a GUI interface for selecting and installing/uninstalling the  
packages.    Those users need plenty of hand-holding and a very  
abstract view of how to install software.   Users who know how to  
actually install the devtools and compile stuff themselves, even if  
it's via "port" vs "make", are quite a few steps above actual Users  
in the food chain and I don't see a lot of benefit (or need) in  
putting extra effort into coddling them.  Just give them the metadata  
they need to make their own decisions and let them get on with it.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070425/cf948be2/attachment.html