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

[Jay Levitt]

Daniel J. Luke wrote:
> 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)

Nope, I totally missed that.  I went straight for the FAQ.  I'm not sure 
if this reflects more on the FAQ, or on my reading comprehension 
skills... OK, I am sure, I just don't like to talk about it.  The doc 
looks great.

Ah, but now I see why I missed it.  Once you go to the FAQ, you're in 
Trac, not the main CMS. So the "Documentation" part of the navigation 
bar (among others) is missing!

I'd recommend that the Trac nav-bar add a third section, rather than 
replacing the "Getting Started" section with its own goodies.

> 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.

Now I'm very confused.  I *did* do a "port selfupdate" and it gave me 
the impression that nothing changed.  (I wish Terminal saved your old 
scrollback buffers so I could see it now...)  Yet, apparently, it did, 
because my edited Portfile is gone, the real Portfile is now the one 
from r34520, and libwww builds just fine.

I'll keep a better logfile next time it happens.

> 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!

What sort of commitment is involved in being a maintainer?  I have a 
sordid history of

1. Feeling a lot of pain when first installing something
2. Swearing that I will be the one to fix it once and for all
3. No longer feeling that pain
4. Look, there's something shiny over there!

That said, I'll be happy to volunteer as a "good god, I must be better 
than no maintainer at all" type maintainer when I find bugs.

> 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.

Oh, absolutely.  I'm a staunch privacy and consent advocate.  It would 
have to be off, opt-in, and as anonymized/obscured as possible.

>> 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).

Good points.  The feedback loop would probably work best as an 
information resource for the maintainer, rather than an automatic 
switch-flipper.  Put one way: Right now we have the degenerate version 
of this.  The "build farm" is whatever platform the maintainer uses (if 
there even is a maintainer), the amount of user feedback is zero, and 
the regression tests are whatever the maintainer happens to try. 
Anything we can add to that is gravy.

>> 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.

Ohhhhh.  That was unclear to me.  So the macports releases like 1.6.0 
are purely macports, not the individual ports?  This is different from 
Linux distros, and might bear mentioning in the FAQ.

> 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.

Yeah, exactly...

> 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.

I promise to try to try....

Jay