Desolate Condition

[Ryan Schmidt]

On Jan 31, 2021, at 11:05, harens wrote:

> I completely agree that Homebrew is currently winning at publicity.

What should the MacPorts community be doing do publicize MacPorts better?


> I think vocalising the points of Saagar Jha’s article Thoughts on macOS Package Managers would be very helpful, since there’s a lot going in MacPorts’ favour:
> 
> 	• MacPorts is much better from a security point of view (considering the whole /usr/local/issue)
> 	• Package availability is much higher, especially for older packages
> 	• There’s support for much older macOS versions
> 	• Being the “pro” tool, there’s a lot more options and functionality
> 	• We don’t send user’s data off as analytics without their permission
> 	• Their community is in shambles after each controversial decision (e.g. Google Analytics, resignation of members)
> 	• etc. etc.

These are good points, and I would not be opposed to a redesign of the MacPorts web site to modernize, remove cruft, highlight what we do well. However I would avoid referring to our competition by name on our web site or pointing out things that we think they do poorly. There have already been a couple efforts in the past years to create new MacPorts web sites; they deserve further consideration.


> We also need to make it easier for users to contribute. About a year ago, I didn’t really know about MacPorts and solely used Homebrew. After I started contributing, I realised how much better MacPorts is, and I’m sure many other new contributors will feel the same.
> 
> I’ve tried to improve the situation with tools like seaport, but to compete with Homebrew’s golden standard brew bump-formula-pr and the Homebrew bump GitHub Action, which allows users to easily contribute without knowing any git, will require some work.

We did already make it easier to contribute by moving to GitHub in late 2016. Moving was difficult, we had resisted it for many years, and it helped that in 2016 Apple paid me to do the move, but even with that incentive, I admit I wasn't convinced that moving to GitHub would improve contributions. But happily it has. I underestimated how many users were familiar with git and wished to contribute by sending pull requests.

Certainly we also still accept contributions from users who are not familiar with git, as we did before we moved to GitHub. Users can continue to submit patches as an attachment to a Trac ticket. Or users could use the GitHub web interface to make a fork and edit a file, all without needing to know how to use git.

I am not familiar with seaport, bump-formula-pr, or Homebrew bump GitHub Action. You could describe them if you like. But I do want to caution against the creation and use of tools that automate updating a port. I recall a batch of PRs some time ago from someone who had clearly just updated the version and checksums of a bunch of ports without ever testing that they built; most of them failed to build in our CI system. Updating version and checksums is all that's needed in the *ideal* case but there are far too many occasions when that is insufficient to be able to recommend relying on an automated tool that only does those things. If updating a port automatically were possible, we'd do it. It's not; it requires human analysis and thought; that's the job of port maintainers.

This hasn't stopped many developers including myself [1] from developing such tools, but they should be used as a first step, not as an only step.

[1] https://github.com/ryandesign/macports-user-ryandesign/blob/master/scripts/portcheckup