On Apr 30, 2008, at 1:23 PM, Jay Levitt wrote:
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?
Have you read the guide? (http://guide.macports.org)
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.
That ticket is marked as fixed and checked in in r34520, so you just need to do 'port selfupdate' or 'port sync' to make sure you have the latest Portfile and you'll already have that fix.
1. What's the right way for an end-user-slash-developer to incorporate bug fixes into my local copy?
it really depends on the workflow you want.One way would be to set up a local portfile repository and put your fixes in there while you test them (the guide describes how to do this), another way would be to check out a copy of the portfiles from svn and point Macports to those portfiles.
You can even do what you did earlier and modify the portfile that macports has already put on your machine (although the next selfupdate or sync you do will get rid of your local changes, then)
2. What's the best way for me to contribute when I find problems like this?
File bugs in trac and assign (or CC) them to the maintainer of the port.It's especially helpful if you've figured out how to fix it and have a patch that you can attach to the bug.
If it's for a port that currently doesn't have a maintainer, it would be great if you would be willing to maintain the port!
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?
nope
Is that under consideration?
I don't think anyone is working on anything like that, there was some discussion in the past, with the takeaway that it would need to be off by default and optionally opt-in if it were something that was even going to be added.
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,
Not ever port has tests available from the upstream, and not every end user has a 'clean' build environment (so this would also require either getting chroot/trace mode/whatever build environment working well enough to make it the default, and probably storing state other than OK/Not OK - since ports could build fine but not work, and it would be difficult to test every port that doesn't already have a comprehensive test suite).
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.
There is currently no stable/unstable distinction for portfiles.I think it would be nice to have something like this, where we have some state associated with each port that would give an indication of what systems the port has been successfully built on (and maybe eventually where it works correctly). If we combined it with some way for multiple versions of the portfile to be available to the end-user they could choose to install the 'newest' portfile, the newest one that has been build tested on similar hardware, or an older version.
Of course, if we end up getting binary packages working well, we might not need any of this support infrastructure.
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?
If you've got the time, it would be great if you would check out the macports code, and try to get (at least some of) your ideas working.
-- Daniel J. Luke +========================================================+ | *---------------- [EMAIL PROTECTED] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
