Issues with oudated ports / GitHub

[Rainer Müller]

Hello Marcel,

On 2016-10-06 19:12, Marcel Bischoff wrote:
> I was advised that I should ask my questions and raise my issues here.
> 
> I'm currently considering dropping the use of MacPorts altogether as
> this projects' track record regarding critical updates of major software
> tools is rather underwhelming. Furthermore, I'm asking myself what use
> it is to have appointed port maintainers when numerous updates are not
> included in a timely manner.

Thank you for coming here to discuss your issues instead of merely
turning your back on the project and leaving silently.

> Just today I commented on a ticket that is six weeks old, about an
> update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
> 4.6.0 on 27-Sep-2016. Version 4 is considered the stable LTS variant,
> only fixing security issues without introducing new features. This makes
> timely updates all the more important. If installing software by hand
> results in more current and more secure software for my development
> machine, I don't get the point of using MacPorts in the first place.

Our ports do have maintainers, which are people who expressed interest
in a port and are interested in keeping them up-to-date. This is meant
to assign issues with ports to certain people that care about this port
and would have the most knowledge how to fix it.

However, we also have a maintainer timeout policy [1] by which updates
to ports can be committed by any project member after 72 hours of
submission if the maintainer does not show any reaction. In case a port
is in a broken state (does not compile at all, typo, etc.) or
vulnerabilities require a security patch, any project member can
immediately commit an update.

In this particular case [2], a ticket was filed with an update request,
but no patch was attached. With a patch, it would be much easier to
verify that the build still works and then commit the update.

The backlog of patches already approved by the maintainer is not that
long [3] right now. Those still in the queue often already went through
review, but issues with the update were found that need to be addressed.

If you think a contribution has stalled, ping the macports-dev list
about it and request a review. This has proved to work quite well in
recent time.

> It pains me to say that Homebrew is running circles around MacPorts in
> the department of current available packages.
> 
> If time and manpower is the problem, wouldn't it be better to move to a
> GitHub-based approach like Homebrew does? This way far more people would
> contribute. It would lower the bar to contributing significantly. I like
> MacPorts' clean implementation far more than Homebrews'. But if I still
> cannot install (for example) pandoc because ghc still requires llwm-3.5
> which does not compile on Sierra: what choice do I have? I need to get
> stuff done, not tinker with the infrastructure of my working environment
> for hours on end, just to get it to work. A package manager's sole
> reason for being is to make the routine task of installing software and
> updates easier, more reliable and trustworthy.

After all, MacPorts maintainers are just some people devoting their free
time to writing Portfiles. Sometimes other stuff in life stops them from
responding to tickets or addressing certain issues.

I can understand your frustration about broken ports and missing
updates. I have that as well.

If your work depends on these ports, you benefit from the donation of
time from the people keeping the port up-to-date. The best you can do if
you encounter a problem is to check if it is a known issue in our Trac.
Sometimes others already proposed a solution but did not have the time
to get through with updating the Portfile in multiple iterations testing
the change. Yes, this is a time-consuming process, but others would
benefit from your work as well as you benefit form theirs.

Just switching to GitHub would not change the way port updates are put
together. In my experience, preparing the patch and attaching it to a
ticket is only a small fraction of what needs to be done for a port
update. You will still need to update the Portfile, test the build, etc.

> The way it is now, I repeatedly find myself in need to modify the
> Portfiles manually, test, check, test again and so on. Or I simply run
> `brew install pandoc` and — be done. Plus, doing all that manual diffing
> where just a minor mistake will frustrate me and requires me to attach a
> completely new diff file quite honestly keeps me from contributing
> regularly. In 2016 this feels like pulling teeth, not satisfaction or a
> sense of accomplishment that should accompany working together on free
> software.

Even as a non-committer you can easily work from a Subversion checkout
with local modifications and create the patch from there. Or you keep a
separate local ports tree that you diff against.

Where exactly do you see the benefit of Git/GitHub for this? I am
honestly interested in this for the upcoming workflow with GitHub.

> I'd really like to hear from several sides about the why's and how's
> regarding MacPorts' current state and what the plan is for the
> forseeable future. I was told that there is a current discussion
> underway about a possible move to GitHub. I would throw whatever weight
> I have behind that move. If you need another helping hand for clearly
> defined work, let me know. I'll be more than happy to involve myself.

This not only a discussion, we already decided and announced this [4].

This is an ongoing process for months now. The port managers worked on
this before the announcement and evaluated various options for the
future of the project. We also gathered input from macports-dev from our
maintainers and eventually reached consensus.

In the last months, lots of time of some core contributors to MacPorts
was already invested into the transition to git, to GitHub and of
everything else away from the closing Mac OS Forge, including our
buildbots. This is time that they would have otherwise been able to put
into the ports they maintain, into ticket reviews or base development.

Personally, I am looking forward to switching to Git/GitHub. When we are
finally through with the move, I hope to be able to focus on ports and
base again instead of the infrastructure.

Rainer

[1] https://guide.macports.org/#project.update-policies.nonmaintainer
[2] https://trac.macports.org/ticket/52110
[3]
https://trac.macports.org/query?status=assigned&status=new&status=reopened&keywords=~haspatch+maintainer&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=time&col=changetime&order=priority
[4]
https://lists.macosforge.org/pipermail/macports-dev/2016-August/033405.html