macfuse

[Jordan K. Hubbard]

On Dec 25, 2011, at 5:22 PM, Scott Webster wrote:

> I might have missed it in the discussion, but what do we gain by
> removing macfuse?  The two things I can think of are: less maintainer
> load for dports and reduced possible confusion for users.

Well, an unmaintained port represents, by some definition, zero maintainer load given that what's abandoned isn't going to take much work, but I think the "possible confusion" angle is closer to what concerns me.  As the number of ports grows, and you have only to look at this graph to see how that can happen to a mature ports collection over time (23,055 ports - ye flippin' gods!), it becomes increasingly difficult to separate the good from the bad.  Do you want a well-tended bazaar, each stall containing high quality goods, or do you want a junk yard, bits of goodness hidden behind walls of almost worthless scrap?  As analogies go, that's perhaps a bit on the dramatic side, but perception also dictates reality to some extent and, as the number of ports which don't build or are otherwise irrelevant grows, the overall negative perception grows with it and folks start jumping to homebrew simply because it's smaller and less cluttered.

I myself only ran into the macfuse port when looking for a working fuse port for my MacBook Air running 10.7, given that "port search" does not rank ports by relevance or quality, and I wasted at least a few minutes trying to build it until I went looking further and found fuse4x.  Multiply that problem by a few orders of magnitude and what's currently only a small annoyance becomes a crisis, so why not just keep the collection clean as a matter of policy (remembering also that everything is under source control and older revisions can always be resurrected with a few keystrokes)?

Perhaps even more importantly, the recent moves to get a buildbot set up for macports (and eventual binary packages) only increases the need to keep the collection build-able and clean lest the number of failures overwhelm the successes, leading maintainers to essentially disregard the buildbot results once there are so many failures that the genuinely fixable ones are swamped by the "won't work and probably never will" build results.

Of course, just to play devil's advocate to myself, macports could also add one or more new port variables to designate ports that are low-quality or known to be broken (FreeBSD has this already) such that "port search" skips them and the buildbot does too, but that seems to me to run the risk of simply enshrining breakage rather than simply GC'ing it properly in the first place and letting the repository provide historical access for those who care.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20111225/126a8001/attachment.html>