macports rot

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

macports rot

Jonathan Stickel-5
I would like to express some concerns about trends I've noticed in the
Macports community. I've been a Macports user and contributor for many
years. I understand the imperfect nature of open-source projects run by
volunteers. Interest and contributions, both by developers and periphery
contributors, waxes and wanes. It seems to me that Macports is waning.
With the move to github, developer and port-maintainer attention to
tickets on trac really dropped off. This was partially made up for by
increased attention and fast turnaround with pull requests. Recently,
even pull requests are languishing. Reasonable fixes are ignored, or, if
problems with the contributions are identified by developers and
maintainers, the problems are pointed out with no effort to provide
constructive input.

I try to help where and when I can. When something is not working for
me, I try my best to find a fix and contribute a pull request. I also
respond in a reasonable time to tickets and PRs for ports for which I am
maintainer. I think this is quite reasonable and the best I can do
considering my paying job. I know that I do not have enough time to act
as a developer, and so I am not asking for that.

So where is Macports headed? I think the core architecture and systems
of Macports are well built. It just needs a little more attention. How
can we achieve that? Has Homewbrew simply siphoned off too much user and
developer base? I don't know.

Regards,
Jonathan
Reply | Threaded
Open this post in threaded view
|

Re: macports rot

Christopher Jones
HI,

I do not agree with your conclusions below. I see no evidence of macports ‘rotting’ in any way. Nor do the GitHub insight statistics, as far as they go, support anything of the sort.

The decrease in use of trac since the move to GitHub is in my opinion completely understandable and OK, as much of what it was used for is now better suited by GitHub directly. So this does not surprise me in the slightest.

The fact there are more open PRs is in my view just a sign that more PRs are being submitted, so the work load in reviewing and applying them is higher. This is perhaps one area we do need to improve, to have more committers taking time to review and merge PRs. This is something that has to a large extent been carried out by  only a handful of people, and thus will be fragile if those people suddenly have less time to devote to it, for whatever reason.

Chris

> On 3 Dec 2018, at 4:00 pm, Jonathan Stickel <[hidden email]> wrote:
>
> I would like to express some concerns about trends I've noticed in the Macports community. I've been a Macports user and contributor for many years. I understand the imperfect nature of open-source projects run by volunteers. Interest and contributions, both by developers and periphery contributors, waxes and wanes. It seems to me that Macports is waning. With the move to github, developer and port-maintainer attention to tickets on trac really dropped off. This was partially made up for by increased attention and fast turnaround with pull requests. Recently, even pull requests are languishing. Reasonable fixes are ignored, or, if problems with the contributions are identified by developers and maintainers, the problems are pointed out with no effort to provide constructive input.
>
> I try to help where and when I can. When something is not working for me, I try my best to find a fix and contribute a pull request. I also respond in a reasonable time to tickets and PRs for ports for which I am maintainer. I think this is quite reasonable and the best I can do considering my paying job. I know that I do not have enough time to act as a developer, and so I am not asking for that.
>
> So where is Macports headed? I think the core architecture and systems of Macports are well built. It just needs a little more attention. How can we achieve that? Has Homewbrew simply siphoned off too much user and developer base? I don't know.
>
> Regards,
> Jonathan


smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: macports challenges (not rot)

Jonathan Stickel-5
As soon as I sent it, I regretted using the word "rot". I should have
used "challenges" or such. Sorry for that.

Maybe it is just my experience with some tickets and PRs that I am
involved with, and not a problem with Macports generally. Nonetheless,
maybe some discussion about how best to move stagnant tickets and PRs
forward might be helpful.

Jonathan



On 12/3/18 10:07, Christopher Jones wrote:

> HI,
>
> I do not agree with your conclusions below. I see no evidence of macports ‘rotting’ in any way. Nor do the GitHub insight statistics, as far as they go, support anything of the sort.
>
> The decrease in use of trac since the move to GitHub is in my opinion completely understandable and OK, as much of what it was used for is now better suited by GitHub directly. So this does not surprise me in the slightest.
>
> The fact there are more open PRs is in my view just a sign that more PRs are being submitted, so the work load in reviewing and applying them is higher. This is perhaps one area we do need to improve, to have more committers taking time to review and merge PRs. This is something that has to a large extent been carried out by  only a handful of people, and thus will be fragile if those people suddenly have less time to devote to it, for whatever reason.
>
> Chris
>
>> On 3 Dec 2018, at 4:00 pm, Jonathan Stickel <[hidden email]> wrote:
>>
>> I would like to express some concerns about trends I've noticed in the Macports community. I've been a Macports user and contributor for many years. I understand the imperfect nature of open-source projects run by volunteers. Interest and contributions, both by developers and periphery contributors, waxes and wanes. It seems to me that Macports is waning. With the move to github, developer and port-maintainer attention to tickets on trac really dropped off. This was partially made up for by increased attention and fast turnaround with pull requests. Recently, even pull requests are languishing. Reasonable fixes are ignored, or, if problems with the contributions are identified by developers and maintainers, the problems are pointed out with no effort to provide constructive input.
>>
>> I try to help where and when I can. When something is not working for me, I try my best to find a fix and contribute a pull request. I also respond in a reasonable time to tickets and PRs for ports for which I am maintainer. I think this is quite reasonable and the best I can do considering my paying job. I know that I do not have enough time to act as a developer, and so I am not asking for that.
>>
>> So where is Macports headed? I think the core architecture and systems of Macports are well built. It just needs a little more attention. How can we achieve that? Has Homewbrew simply siphoned off too much user and developer base? I don't know.
>>
>> Regards,
>> Jonathan
>
Reply | Threaded
Open this post in threaded view
|

Re: macports rot

Rainer Müller-4
In reply to this post by Jonathan Stickel-5
On 03.12.18 17:00, Jonathan Stickel wrote:

> I would like to express some concerns about trends I've noticed in the
> Macports community. I've been a Macports user and contributor for many
> years. I understand the imperfect nature of open-source projects run by
> volunteers. Interest and contributions, both by developers and periphery
> contributors, waxes and wanes. It seems to me that Macports is waning.
> With the move to github, developer and port-maintainer attention to
> tickets on trac really dropped off. This was partially made up for by
> increased attention and fast turnaround with pull requests. Recently,
> even pull requests are languishing. Reasonable fixes are ignored, or, if
> problems with the contributions are identified by developers and
> maintainers, the problems are pointed out with no effort to provide
> constructive input.
>
> I try to help where and when I can. When something is not working for
> me, I try my best to find a fix and contribute a pull request. I also
> respond in a reasonable time to tickets and PRs for ports for which I am
> maintainer. I think this is quite reasonable and the best I can do
> considering my paying job. I know that I do not have enough time to act
> as a developer, and so I am not asking for that.

Your observation might be right, but maybe this just becomes more
visible now on GitHub. Just take a look at the number of open tickets on
Trac. There are also many tickets with proposed ports or fixes. However,
if the submitter does not have enough interest to follow through, the
ticket will just hang there.

I feel like many "oldschool" developers already left the platform,
because more and more functionality is put behind some wall that only
Apple can penetrate. Gatekeeper, signed Kernel Extension, and SIP impose
limits on what you can do with macOS, while non-Apple developers do not
even get proper logging when APIs become forbidden and blocked.

I guess that users coming to macOS now are used to graphical interfaces
and do not have a strong background in using the command line. I am sure
many are more happy with Homebrew, where they do not even have to use
sudo! ;-)

Somehow the Homebrew community managed to get their ubiquitous marketing
on almost every software project website. Compare this with the MacPorts
website, which has not seen any redesign in more than 10 years...

Although a good package management system should not need to advertise
itself, as every software would be available without users being told
where to look – the package manager should be their first choice.

> So where is Macports headed? I think the core architecture and systems
> of Macports are well built. It just needs a little more attention. How
> can we achieve that? Has Homewbrew simply siphoned off too much user and
> developer base? I don't know.

I would also like to point out that there was also no discussion on the
recent thread that we have a problem with the process to on-board new
project members... That is one of the most important things that needs
to be solved as it affects the whole community.

Similarly on the recently failed online meeting and especially the topic
of joining the Software Freedom Conservancy or more general to form any
kind of legal entity.

The project definitely needs more steering. But to be fair and
transparent on this, I am personally not able to provide this at the moment.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: macports rot

Mark Anderson-10
Yeah Rainer, I was surprised that that thread went nowhere. I’m ok with not being ready to be on boarded or needing to learn more, but it’s still been radio silence. 

The thing is I still am a much bigger fan of this project and community than Homebrew. I’ve been thinking of an idea to compete with Cask. I’m trying to take over things that are no maintainer that I want to use. I’ve been on MacPorts since 10.3 and I don’t want it to die or languish. But I’m not sure exactly what to do. I’m certainly only going to homebrew kicking and screaming. I remember those early nasty advertisements focused on this community. 

I really want to get more involved, help with tooling, maybe get a Swift MacPorts.framework working. But I have no idea how. If anyone has ideas I’m looking to dive in and I’m on Eastern Time. I’ve asked for commit access and bumped portmgr a few times, but other than that I don’t know exactly how to help. 

—Mark


Your observation might be right, but maybe this just becomes more
visible now on GitHub. Just take a look at the number of open tickets on
Trac. There are also many tickets with proposed ports or fixes. However,
if the submitter does not have enough interest to follow through, the
ticket will just hang there.

I feel like many "oldschool" developers already left the platform,
because more and more functionality is put behind some wall that only
Apple can penetrate. Gatekeeper, signed Kernel Extension, and SIP impose
limits on what you can do with macOS, while non-Apple developers do not
even get proper logging when APIs become forbidden and blocked.

I guess that users coming to macOS now are used to graphical interfaces
and do not have a strong background in using the command line. I am sure
many are more happy with Homebrew, where they do not even have to use
sudo! ;-)

Somehow the Homebrew community managed to get their ubiquitous marketing
on almost every software project website. Compare this with the MacPorts
website, which has not seen any redesign in more than 10 years...

Although a good package management system should not need to advertise
itself, as every software would be available without users being told
where to look – the package manager should be their first choice.

> So where is Macports headed? I think the core architecture and systems
> of Macports are well built. It just needs a little more attention. How
> can we achieve that? Has Homewbrew simply siphoned off too much user and
> developer base? I don't know.

I would also like to point out that there was also no discussion on the
recent thread that we have a problem with the process to on-board new
project members... That is one of the most important things that needs
to be solved as it affects the whole community.

Similarly on the recently failed online meeting and especially the topic
of joining the Software Freedom Conservancy or more general to form any
kind of legal entity.

The project definitely needs more steering. But to be fair and
transparent on this, I am personally not able to provide this at the moment.

Rainer
--
Sent from Gmail Mobile on iPhone
Reply | Threaded
Open this post in threaded view
|

Re: macports rot

Nils Breunese
In reply to this post by Rainer Müller-4
Rainer Müller wrote:

Somehow the Homebrew community managed to get their ubiquitous marketing
on almost every software project website. Compare this with the MacPorts
website, which has not seen any redesign in more than 10 years...

Although a good package management system should not need to advertise
itself, as every software would be available without users being told
where to look – the package manager should be their first choice.

But you need to know about this package manager first then. And be convinced into installing and using it. I found out about the existence of package managers on Mac (I guess it was Fink for me at the time) through installation instructions for some tool I wanted to install.

When I started to maintain some packages for MacPorts I also made an effort to do pull requests for the install docs to add instructions for installing via MacPorts (for instance [0]). I think this is very important PR for a package manager, apart from its own website.

For instance, yesterday I wanted to try out Hugo. It’s available in MacPorts, but the Hugo site only mentions Homebrew, binary download and building from source as installation options [1]. I think it might pay off if maintainers would pay more attention to this.

Nils.

Reply | Threaded
Open this post in threaded view
|

Re: macports challenges

Jonathan Stickel-5
I'm glad to see some constructive discussion. After I sent the email, I
was quite worried of the negative tone, and that it might be perceived
as trolling. Sorry if that is true; it was not my attention.

On 12/6/18 01:13, Nils Breunese wrote:

> Rainer Müller wrote:
>
>> Somehow the Homebrew community managed to get their ubiquitous marketing
>> on almost every software project website. Compare this with the MacPorts
>> website, which has not seen any redesign in more than 10 years...
>>
>> Although a good package management system should not need to advertise
>> itself, as every software would be available without users being told
>> where to look – the package manager should be their first choice.
>
> But you need to know about this package manager first then. And be
> convinced into installing and using it. I found out about the existence
> of package managers on Mac (I guess it was Fink for me at the time)
> through installation instructions for some tool I wanted to install.
>
> When I started to maintain some packages for MacPorts I also made an
> effort to do pull requests for the install docs to add instructions for
> installing via MacPorts (for instance [0]). I think this is very
> important PR for a package manager, apart from its own website.
>
> For instance, yesterday I wanted to try out Hugo. It’s available in
> MacPorts, but the Hugo site only mentions Homebrew, binary download and
> building from source as installation options [1]. I think it might pay
> off if maintainers would pay more attention to this.
>

This is a great idea. When a new port is added, the maintainer (or
requester) should be encouraged to facilitate docs/instructions/notes
upstream that the software is available in macports. (I wouldn't make it
a requirement -- requirements can be perceived as draconian and keep
people away.) Is there a place in the guide or wiki to say this? Maybe
chapter 4 of the guide, "Portfile Development"?

I'll work on retroactively doing this for the ports for which I am
maintainer.


> Nils.
>
> [0]
> https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-macports-cli-installation
> [1] https://gohugo.io/getting-started/installing#pick-your-method
Reply | Threaded
Open this post in threaded view
|

Re: macports challenges

Ruben Di Battista
I wanted to provide my feedback w.r.t. this topic. 

I also contribute to other “package manager”, a bit more tailored to HPC (EasyBuild and Spack) and in my opinion, more than the actual advertisement, the real hindering factor for Macports is TCL. TCL is hard, at least compared to Ruby or Python. It has a soul that is more oriented towards scripting than programming, and it makes hard to dive into port development. 

Another aspect that in my opinion is lacking at Macports side is a deep documentation on Portfile development. For example I still don’t know how most of the PortGroups work and often my workflow is to identify a well known port that makes use of a specific PortGroup and replicate most of the behavior (or otherwise looking directly in the source of the PortGroup). If we compare with Spack package.py development docs or EasyBuild easyconfigs/easyblocks I think we can easily highlight a documentation debt. 

Another aspect I would like to highlight, and this is more personal maybe, is related to the communication interaction w/ the community. I find myself the mailing list sort of obsolete. Moreover, very often, there’s an overlap between the subjects in macports-users and the ones of macports-dev. Again, both Spack and EB communities are on Slack.  I’m not here endorsing a proprietary, non-free, platform (there are FOSS alternatives), but I find the “ChatOps” movement and communication strategy very effective to promote community interaction.

Just my 2¢ :)

          _   
-.     .´  |∞∞∞∞
  ',  ;    |∞∞∞∞∞∞
    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB
    ,.,    |∞∞∞∞∞∞
  .'   '.  |∞∞∞∞
-'       `’

https://rdb.is

On 6 dicembre 2018 a 15:28:37, Jonathan Stickel ([hidden email]) scritto:

I'm glad to see some constructive discussion. After I sent the email, I
was quite worried of the negative tone, and that it might be perceived
as trolling. Sorry if that is true; it was not my attention.

On 12/6/18 01:13, Nils Breunese wrote:

> Rainer Müller wrote:
>
>> Somehow the Homebrew community managed to get their ubiquitous marketing
>> on almost every software project website. Compare this with the MacPorts
>> website, which has not seen any redesign in more than 10 years...
>>
>> Although a good package management system should not need to advertise
>> itself, as every software would be available without users being told
>> where to look – the package manager should be their first choice.
>
> But you need to know about this package manager first then. And be
> convinced into installing and using it. I found out about the existence
> of package managers on Mac (I guess it was Fink for me at the time)
> through installation instructions for some tool I wanted to install.
>
> When I started to maintain some packages for MacPorts I also made an
> effort to do pull requests for the install docs to add instructions for
> installing via MacPorts (for instance [0]). I think this is very
> important PR for a package manager, apart from its own website.
>
> For instance, yesterday I wanted to try out Hugo. It’s available in
> MacPorts, but the Hugo site only mentions Homebrew, binary download and
> building from source as installation options [1]. I think it might pay
> off if maintainers would pay more attention to this.
>

This is a great idea. When a new port is added, the maintainer (or
requester) should be encouraged to facilitate docs/instructions/notes
upstream that the software is available in macports. (I wouldn't make it
a requirement -- requirements can be perceived as draconian and keep
people away.) Is there a place in the guide or wiki to say this? Maybe
chapter 4 of the guide, "Portfile Development"?

I'll work on retroactively doing this for the ports for which I am
maintainer.


> Nils.
>
> [0]
> https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-macports-cli-installation
> [1] https://gohugo.io/getting-started/installing#pick-your-method

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: macports rot

Calvin Ardi
In reply to this post by Nils Breunese
Hi Nils,

On Thu, Dec 06, 2018 at 09:13:38AM +0100, Nils Breunese wrote:
> For instance, yesterday I wanted to try out Hugo. It’s available in
> MacPorts, but the Hugo site only mentions Homebrew, binary download
> and building from source as installation options [1]. I think it might
> pay off if maintainers would pay more attention to this.
>
> Nils.
>
> [1] https://gohugo.io/getting-started/installing#pick-your-method

I am (at the moment) the package maintainer for Hugo.

Thanks for the comments. Publicizing the MacPorts package for Hugo, on
the Hugo site, is a great idea. I haven't looked into it because
Hugo's publicity hadn't crossed my mind, nor am I involved in the
upstream project in any way (my primary motivation for maintaining the
Portfile is driven by my own desire to use Hugo).

As a new-ish maintainer, I do rely heavily on the MacPorts Guide [1], so
something like "notify upstream about the MacPorts package" might be a
good item to add on a checklist in Portfile Development.

--calvin

[1] https://guide.macports.org/