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
