HOWTO: Get started, gain macports-foo, make bad first impression

[Jay Levitt]

[Note to self: MacBook Pro enter key is very, very close to left-arrow 
key.  Sorry about that.]

I don't expect to become a port maintainer, but I do find myself running 
into port bugs that already have fixes in trunk, or that I know how to 
fix.  If nothing else, I'm usually able to build a package successfully 
from source, which means that I should, in theory, be able to integrate 
the latest source into macports.

But I have absolutely no idea how to go about incorporating others' 
fixes, or trying and submitting my own.  And the FAQ doesn't have a "how 
can I get involved" section.  Any tips/pointers?

For example:  I just tried installing jigdo.  That port relies on 
libwww, which is currently broken for some configurations.  Ticket 
#12851 (http://trac.macosforge.org/projects/macports/ticket/12851) fixes 
this, and it refers to changeset r34520, a patch to 
trunk/dports/www/libwww/Portfile.

I applied that change to my local copy of the Portfile, in 
/opt/local/var/macports/sources/rsync.macforge.org/release/ports/www/libwww. 
  That didn't make MacPorts happy; now I get:

bash-3.2# port clean libwww
Portfile changed since last build; discarding previous state.
--->  Cleaning libwww
bash-3.2# port install libwww
--->  Fetching libwww
--->  Attempting to fetch patch-configure.diff from 
http://svn.macports.org/repository/macports/distfiles/libwww
--->  Attempting to fetch patch-configure.diff from 
http://svn.macports.org/repository/macports/distfiles/general/
--->  Attempting to fetch patch-configure.diff from 
http://svn.macports.org/repository/macports/downloads/libwww
Error: Target org.macports.fetch returned: fetch failed
Error: Status 1 encountered during processing.

Soooo...

1. What's the right way for an end-user-slash-developer to incorporate 
bug fixes into my local copy?

2. What's the best way for me to contribute when I find problems like this?

As an end-user, the current MacPorts site is confusing.  Knowing that 
each port is maintained by some individual (or, often, nobody at all), 
I'd expect to be able to find a list of ports, click on it, and see the 
latest version, some info about the port, a list of related bugs, etc.

Instead, all the bugs are in a single Trac database.  If I go to 
"Available Ports", and enter "libwww" in the search field, I see 
"libwww" as one of the two choices.  I click on libwww and get... Trac's 
pretty-print of the Portfile from SVN. So:

3. Are there any ongoing projects to create a better, er, port-al?

4. I saw a discussion about parallel builds, and how you can't enable 
them by default.  Does "port" send any phone-home info about build 
failures/successes?   Is that under consideration?

It seems to me that the best solution for this, and for any breaking 
change, would be to allow end users to opt-in and become part of the 
macports "build farm".  Instead of a yes/no flag for parallel builds, 
add a third state: experimental.  Experimental would build everything in 
parallel, run the unit tests, and report back to macosforge.  If we see 
it working on enough "supported platforms", we could flip the Big Switch 
and move that to the stable distribution.

In fact, now that I think about it, this could help a lot of the 
problems I've run into, all of which appear to be "no longer works on 
the latest OS/hardware/whatever but the port maintainer doesn't run that".

Thoughts?

Jay Levitt