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