Proposal for a new repository layout
Jordan K. Hubbard
jkh at brierdr.com
Wed Apr 25 18:13:27 PDT 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev