Re: Publicizing MacPorts

[Georges Martin]

Done: https://github.com/macports/macports-ports/pull/10726

> Le 19 avr. 2021 à 23:46, Clemens Lang  a écrit :
> 
> Hi,
> 
> On Mon, Apr 19, 2021 at 07:58:02PM +0200, Georges Martin wrote:
>> Speaking of the PR checklist, the "Tested On" section could include the 
>> architecture name:
>> 
>>  echo "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion) on 
>> $(uname -m)"
>> 
>> As I'm now testing both on x86_64 and arm64, that's something I try to 
>> include in my PRs...
> 
> Very nice idea. See
> https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md,
> which contains this. Could you submit a PR for the change?
> 
> -- 
> Clemens

Re: Publicizing MacPorts

[Clemens Lang]

Hi,

On Mon, Apr 19, 2021 at 07:58:02PM +0200, Georges Martin wrote:
> Speaking of the PR checklist, the "Tested On" section could include the 
> architecture name:
> 
>   echo "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion) on 
> $(uname -m)"
> 
> As I'm now testing both on x86_64 and arm64, that's something I try to 
> include in my PRs...

Very nice idea. See
https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md,
which contains this. Could you submit a PR for the change?

-- 
Clemens

Re: Publicizing MacPorts

[Craig Treleaven]

> On Apr 19, 2021, at 2:51 PM, Jason Liu  wrote:
> 
> On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven  > wrote:
> Also, why should we consider that MacPorts is in competition with Homebrew?  
> Both MacPorts and Homebrew seem to have a sufficient number of contributors 
> to keep going for the foreseeable future.  Nether packaging system has to 
> "win" nor does the other have to "lose".  The projects do have differing 
> philosophies that may make one more suitable than the other for particular 
> users.
> 
> Although this is a nice sentiment, I believe the reality is that MacPorts is 
> in fact in competition with Homebrew. And not just Homebrew, but with other 
> package managers as well, such as Munki, and even to some extent other 
> deployment products such as Jamf/Casper and Jenkins. My belief is that the 
> total number of systems running macOS as its operating system is the entire 
> "pie" of systems that could potentially use one of these macOS package 
> managers. In addition, the vast majority of users will only use one package 
> management product, hence my opinion of why it's a pie with a limited number 
> of potential users that gets divided up. The possible exception to only using 
> one product per machine might be, say, in an enterprise setting (you can read 
> my personal anecdote below for an example).
> 
> In addition, it has traditionally been the case that package management 
> systems say on their websites that installing multiple package managers on 
> one machine can cause problems... e.g. MacPorts doesn't work well with Fink 
> and Homebrew, Homebrew doesn't work well with Fink and MacPorts, etc. People 
> on this mailing list are tech savvy enough to deal with the potential 
> conflicts that might occur regarding environment variables, $PATH order, etc. 
> but the vast majority of users won't be, and thus would stick to using only 
> one package manager. If one product "wins" by getting installed on a 
> particular system, then the others "lose”.
> 


I wasn’t trying to suggest that a user should install multiple package managers.

MacPorts needs contributors and maintainers to go forward.  We don’t _need_ 
users!  It is the same amount of work to create or update a package regardless 
of the number of users.  Several of the packages I maintain have very few 
reported users…sometimes only me.  

As long has we have a decent volume of people contributing to MacPorts the 
project will continue.  As a port maintainer, it is gratifying to think that my 
work may be benefiting others.  It is not that important whether it is 10 
people or 10,000.  I think that many of our maintainers do so because they need 
the ports that they are working on.  IOW, they’d do so even if there were no 
other users.  Obviously, several of our most prolific maintainers have 
different motivations.

To be cynical, I think Homebrew users are more commonly command line newbies 
and therefore probably generate a high volume of simple and repetitive 
questions.   AKA ’support desk hell’!  Perhaps we are fortunate that MacPorts 
users tend to be a little more savvy.  ;)

Craig

Re: Publicizing MacPorts

[Jason Liu]

On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven 
wrote:

> Also, why should we consider that MacPorts is in competition with
> Homebrew?  Both MacPorts and Homebrew seem to have a sufficient number of
> contributors to keep going for the foreseeable future.  Nether packaging
> system has to "win" nor does the other have to "lose".  The projects do
> have differing philosophies that may make one more suitable than the other
> for particular users.
>

Although this is a nice sentiment, I believe the reality is that MacPorts
is in fact in competition with Homebrew. And not just Homebrew, but with
other package managers as well, such as Munki, and even to some extent
other deployment products such as Jamf/Casper and Jenkins. My belief is
that the total number of systems running macOS as its operating system is
the entire "pie" of systems that could potentially use one of these macOS
package managers. In addition, the vast majority of users will only use one
package management product, hence my opinion of why it's a pie with a
limited number of potential users that gets divided up. The possible
exception to only using one product per machine might be, say, in an
enterprise setting (you can read my personal anecdote below for an example).

In addition, it has traditionally been the case that package management
systems say on their websites that installing multiple package managers on
one machine can cause problems... e.g. MacPorts doesn't work well with Fink
and Homebrew, Homebrew doesn't work well with Fink and MacPorts, etc.
People on this mailing list are tech savvy enough to deal with the
potential conflicts that might occur regarding environment variables, $PATH
order, etc. but the vast majority of users won't be, and thus would stick
to using only one package manager. If one product "wins" by getting
installed on a particular system, then the others "lose".



Personal Anecdote

In one of my former lives, I used to work as a systems administrator for
one of the science departments at a local university, and we used more than
one package management system (PMS) on our Macs. The central,
university-wide IT support group used a combination of Munki and Jenkins to
deploy proprietary commercial software that requires license keys, such as
Adobe and Microsoft products. The department-level IT support staff have
superuser access on each of the computers, but we didn't have the ability
to contribute our own software packages to the central IT's Munki/Jenkins
servers. So, several science departments banded together to also deploy
MacPorts on their departments' Macs, so that we could manage software
packages that were of interest to the individual departments. We were also
aware of other departments that used Homebrew as their departmental PMS. In
fact, the central IT group even added a Homebrew "installer" to the list of
software available through Munki, but refused to add the MacPorts installer
(the sysadmin that was the head of managing the Munki servers loved
Homebrew and Ruby, and absolutely hated Tcl).

This is one of the few instances where I could see the benefit of having
more than one PMS installed on the same machine. But for home computers
that are being managed by a single family member, or even computers
(laptops) that are only ever used by a single person, I highly doubt that
they would willingly go through the hassle of obtaining their software
through more than one PMS.

-- 
Jason Liu


On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven 
wrote:

> > On Apr 19, 2021, at 10:47 AM, Karl-Michael Schindler <
> karl-michael.schind...@physik.uni-halle.de> wrote:
> >
> > Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
> >>
> >> Date: Mon, 19 Apr 2021 13:24:51 +0200
> >> From: Mojca Miklavec 
> >> Subject: Re: Publicizing MacPorts
> >> Message-ID: <
> calbomsbrso9ao2sgvonvp69hskephjiwzhscmwmi_f6cfay...@mail.gmail.com>
> >> Content-Type: text/plain; charset="UTF-8"
> >>
> >> We should probably be publicising that MacPorts works just fine with
> >> M1 more aggressively from the very beginning.
> >>
> >> If anyone is willing to volunteer to do PR for MacPorts ...
> >>
> >> Mojca
> >
> > I intend to do so, probably to a limited extend only. As a first step, I
> have checked the upstream download pages of our top ten downloads. Less
> than 5 of them mention macports properly. My next steps is to write to
> them. I also want to extent the maintainer part of the docs with the direct
> to port maintainer to check upstream download and install pages.
> >
> > Michael.
>
> People don’t install MacPorts or Homebrew just to have a package
> manager—they install a package manager as a prerequisite to get software
> that they want.  So getting popular software packages to mention that
> MacPorts can install that software is very important.
>
> Also, why should we consider that MacPorts is in competition with
> Homebrew?  Both MacPorts and Homebrew seem to have a sufficient number of
> 

Re: Publicizing MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

It would be very helpful for new impressions of Macports, if the ports
website could be fixed to properly show current port status.  This problem
has been lingering for months now:

https://github.com/macports/macports-webapp/issues/273


On Mon, Apr 19, 2021 at 9:59 AM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> Here are a few ideas.  How many M1 ports are working on Macports?  How
> many on Homebrew and other competitors?
>
> How long ago did Macports start to have working M1 ports?
>
> Are there any noteworthy M1 ports that are working on Macports, but not on
> Homebrew?
>
>
> On Mon, Apr 19, 2021 at 8:47 AM Rainer Müller  wrote:
>
>>
>> So, if MacPorts were to make an announcement now, what would you put in
>> there?
>> Can you show us a draft? "MacPorts works like it always has" is barely
>> newsworthy.
>>
>

Re: Publicizing MacPorts

[Craig Treleaven]

> On Apr 19, 2021, at 10:47 AM, Karl-Michael Schindler 
>  wrote:
> 
> Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
>> 
>> Date: Mon, 19 Apr 2021 13:24:51 +0200
>> From: Mojca Miklavec 
>> Subject: Re: Publicizing MacPorts
>> Message-ID: 
>> 
>> Content-Type: text/plain; charset="UTF-8"
>> 
>> We should probably be publicising that MacPorts works just fine with
>> M1 more aggressively from the very beginning.
>> 
>> If anyone is willing to volunteer to do PR for MacPorts ...
>> 
>> Mojca
> 
> I intend to do so, probably to a limited extend only. As a first step, I have 
> checked the upstream download pages of our top ten downloads. Less than 5 of 
> them mention macports properly. My next steps is to write to them. I also 
> want to extent the maintainer part of the docs with the direct to port 
> maintainer to check upstream download and install pages.
> 
> Michael.

People don’t install MacPorts or Homebrew just to have a package manager—they 
install a package manager as a prerequisite to get software that they want.  So 
getting popular software packages to mention that MacPorts can install that 
software is very important.  

Also, why should we consider that MacPorts is in competition with Homebrew?  
Both MacPorts and Homebrew seem to have a sufficient number of contributors to 
keep going for the foreseeable future.  Nether packaging system has to “win” 
nor does the other have to "lose”.  The projects do have differing philosophies 
that may make one more suitable than the other for particular users.  For 
example, Homebrew only aims to support recent hardware and up-to-date operating 
system versions even if users are sometimes left behind.  MacPorts makes far 
greater efforts to ensure packages work on older hardware and OS versions.  We 
might do a better job of explaining how MacPorts differs so that users can make 
an informed choice.

My $0.02 (and Canada doesn’t even have pennies anymore!).

Craig

Re: Publicizing MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

Here are a few ideas.  How many M1 ports are working on Macports?  How many
on Homebrew and other competitors?

How long ago did Macports start to have working M1 ports?

Are there any noteworthy M1 ports that are working on Macports, but not on
Homebrew?


On Mon, Apr 19, 2021 at 8:47 AM Rainer Müller  wrote:

>
> So, if MacPorts were to make an announcement now, what would you put in
> there?
> Can you show us a draft? "MacPorts works like it always has" is barely
> newsworthy.
>

Re: Publicizing MacPorts

[Karl-Michael Schindler]

Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
> 
> Date: Mon, 19 Apr 2021 13:24:51 +0200
> From: Mojca Miklavec 
> Subject: Re: Publicizing MacPorts
> Message-ID: 
> 
> Content-Type: text/plain; charset="UTF-8"
> 
> We should probably be publicising that MacPorts works just fine with
> M1 more aggressively from the very beginning.
> 
> If anyone is willing to volunteer to do PR for MacPorts ...
> 
> Mojca

I intend to do so, probably to a limited extend only. As a first step, I have 
checked the upstream download pages of our top ten downloads. Less than 5 of 
them mention macports properly. My next steps is to write to them. I also want 
to extent the maintainer part of the docs with the direct to port maintainer to 
check upstream download and install pages.

Michael.

Re: Publicizing MacPorts

[Rainer Müller]

On 19/04/2021 15.14, Steven Smith wrote:

If you have contacts to tech reporters, please use them. I don't have any. If 
Ars Technica or any other news site wants to cover MacPorts, they can do that 
any time.


This is the wrong attitude.

MacPorts must tell them, not some random user/contributer like me.


In my opinion, users have to spread the word to make MacPorts more popular.


And the press likely won’t think an issue is important or interesting enough to 
cover if the related organization doesn’t think it’s interesting enough to post 
an announcement about it.


They are much more likely to post an article if they know users will be 
interested in it.


So, if MacPorts were to make an announcement now, what would you put in there? 
Can you show us a draft? "MacPorts works like it always has" is barely newsworthy.


Rainer

Re: Publicizing MacPorts

[Steven Smith]

> If you have contacts to tech reporters, please use them. I don't have any. If 
> Ars Technica or any other news site wants to cover MacPorts, they can do that 
> any time.

This is the wrong attitude. 

MacPorts must tell them, not some random user/contributer like me.

Everyone has tech reporter contacts: their email and Twitter handle and contact 
info is all posted online with every article.

And the press likely won’t think an issue is important or interesting enough to 
cover if the related organization doesn’t think it’s interesting enough to post 
an announcement about it. 


> On Apr 19, 2021, at 07:48, Rainer Müller  wrote:
> 
> If you have contacts to tech reporters, please use them. I don't have any. If 
> Ars Technica or any other news site wants to cover MacPorts, they can do that 
> any time.

Re: Publicizing MacPorts

[Steven Smith]

> We never made any announcement since it basically "worked from day 1"


Then that’s the announcement!

No one will know this stuff if MacPorts doesn’t tell them.

There must be one or two regular broadcast channels: perhaps a blog on your 
website for major announcer, and Twitter feed for regular highlighted items of 
interest, perhaps featured upgrades or MacPorts-specific ports and news.


> On Apr 19, 2021, at 07:25, Mojca Miklavec  wrote:
> 
> We never made any announcement since it basically "worked from day 1"

Re: Publicizing MacPorts

[Rainer Müller]

On 19/04/2021 12.45, Steven Smith wrote:

"Champion" how?

"MacPorts should be making [the case]" how?


The same way everyone else does: make noise, push news, promote, let the tech 
reporters know. Follow the Woody Allen rule for success.


If a comparable announcement to this was made for MacPorts, I missed it:

https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/ 



If you have contacts to tech reporters, please use them. I don't have any. If 
Ars Technica or any other news site wants to cover MacPorts, they can do that 
any time.


Maybe we could sent out news to macports-announce about support of new macOS 
releases as well as the arm64 architecture. But at which point would you do it? 
There are continuously updated ports with support or fixes for arm64. The 
announcement for 2.6.4 in November [1] briefly mentioned the support for arm64. 
But I don't know what more to say, because... it just works? ;-)


MacPorts 2.0 that introduced binary archives also got news coverage, which was 
mostly because we increased the major version number. Homebrew did the same 
thing now, because they had to make changes to support an additional 
architecture, thus they got the news coverage. MacPorts did not need that many 
changes to support arm64, because it had the general support for multiple 
architectures already.


Rainer

[1] 
https://lists.macports.org/pipermail/macports-announce/2020-November/57.html

Re: Publicizing MacPorts

[Mojca Miklavec]

On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:
>
> If a comparable announcement to this was made for MacPorts, I missed it:
>
> https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/

We never made any announcement since it basically "worked from day 1"
(almost), and we never had any specific point in time when support for
M1 was significantly improved. (We probably needed an upgrade of
MacPorts base, but that happened very soon.)

We should probably be publicising that MacPorts works just fine with
M1 more aggressively from the very beginning.

If anyone is willing to volunteer to do PR for MacPorts ...

Mojca

Re: Publicizing MacPorts

[Ryan Schmidt]

On Apr 18, 2021, at 07:28, Steven Smith wrote:

>>> I completely agree that Homebrew is currently winning at publicity.
>> 
>> What should the MacPorts community be doing do publicize MacPorts better?
> 
> The new M1 architecture is a perfect opportunity to champion MacPorts’s 
> strengths:
> 
> • Strong emphasis on binaries built from source code, often specifically 
> patched
> • Strong emphasis on smart, solid engineering with high quality, reliable 
> installs
> • Extraordinarily comprehensive coverage across both software and 
> architectures
> • Expert, engaged, and helpful development community
> 
> We’re seeing all these strengths play out in MacPorts’s successful and 
> ongoing migration to the new M1 chip.
> 
> We’re also seeing the contrast of how Homebrew’s undesirable design 
> decisions, reliance on external binaries, and other shortcuts affect its 
> migration to the M1: https://github.com/Homebrew/brew/issues/7857
> 
> This is an easy case to make, and MacPorts should be making it, using the M1 
> as a banner example.

Sure.

"Champion" how?

"MacPorts should be making [the case]" how?

I know our main web site needs an overhaul, and drawing attention to some of 
these facts there would be good. In what other ways, what other venues, do you 
envision this information being communicated?