First, I think this is a great idea and thanks go to whomever suggested it - MacPorts is full of the sorts of projects that summer- of-coders could do in the time allotted. Second, before google is even approached I think the project needs to pull a wish-list together and demonstrate that it's not just looking for some free labor to get a bit of grunt work done, it's got some project ideas that will really move the project forward and demonstrably improve its utility to the Macintosh community at large. I've been one of the google SoC mentors (for FreeBSD) and I can say that the project ideas which tend to get funding aren't the ones which go "clean up our man pages and look for typos", they're more along the lines of "port ZFS to FreeBSD". Furthermore, I *know* that MacPorts has a number of long-stalled efforts in base/ which are just waiting for someone to go dive on them single-mindedly. Just thinking right off the top of my head, some of these are: 1. Finish the work Paul Guyot started with the trace code and create real "virtual chroot" environments for building ports, constraining what their configure scripts can see and validating that their explicit dependencies are correct and fully-formed. 2. Working in concert (or cooperatively) with whomever does #1, get package building working all the way to a point where complete package builds can be done for all of MacPorts and the results made available to users as pre-build package collections. 3. Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users. 4. Take what Will started with the notion of a depot location vs an installed location (e.g. /opt/local/var/db/dports/software/gawk/ 3.1.5_2/opt/local/bin/gawk vs /opt/local/bin/gawk) and finish the job, making depot-to-depot dependencies finally work. That is to say that if port foo depends on version 1.2.3 of port bar, it should be compiled and linked in such a way that it's wired to the depot location of bar, not the "activated" location. That will finally fix the fragility problem where deactivating port bar vers n-1 in order to install port bar vers n (because other things depend on n) won't also require breaking everything that relies on n-1. 5. Sweep through all Portfiles and look for useful opportunities to add more built-in Tcl functions that make Portfiles more (usefully) terse, powerful, flexible or easier to write. I'm sure there is an entirely family of helper functions yet to be written here. That's just 5 off the top of my head with about the same number of minutes work devoted to pulling them out of my memory. I know that I've seen easily 10 times that many "good idea, someone should do that!" emails fly by the lists over the last few years too, so I'm sure others can easily add to this list. Approaching google is also something that shouldn't be done ad-hoc by a number of people all claiming to represent macports in some way. Someone wearing the portmgr mantle needs to collect all these ideas, get some democratic input as to which ideas are truly the best, then approach google with the list and try to get added as a SoC project. They need to do it quickly too since we don't have much time. I nominate jmpp. - Jordan