ksh93

[Mojca Miklavec]

On Fri, 15 Nov 2019 at 23:46, joerg van den hoff wrote:
> On 15.11.19 23:00, Christopher Jones wrote:
>  >
>  >> Hello,
>  >>    If you put in a ticket to https://trac.macports.org/wiki/Tickets
> <https://trac.macports.org/wiki/Tickets> it can be monitored.  It is up
> to the maintainer or someone else to update.
>  >
>  > or, even better, submit a PR with the update yourself at
>  >
>  > https://github.com/macports/macports-ports/pulls
> <https://github.com/macports/macports-ports/pulls>
>
> a pull request? really? I mean, no offense meant (promise!) but the
> macports project sure has a policy for its maintained packages regarding
> updating them automatically on a regular basis?

MacPorts, as well as many other projects, is run by volunteers
receiving precisely zero money in exchange for their effort, and
anyone is welcome to join the team at any time.

Our biggest problem are unmaintained packages (which we have a lot
more than maintained ones), and for the explicitly maintained packages
it very often turns out that some people have abandoned the project
and we no longer have a way to reach them, and if we notice that, we
try to remove maintainers from packages.

Maintainers are generally expected to keep their packages up to date,
but most of them have "real life" as well :)

Depending on the volunteer, they would check for outdated packages
from time to time, but if there's an explicit request to deal with
something before they notice it, there's a bigger chance that a
package will be updated before others.

The "maintained" package that you are referring to belong to a
maintainer taking care of over 1000 packages
(https://ports.macports.org/maintainer/github/ryandesign/), and I can
tell you that updating some packages might literally take days, or
very often at least hours to get it done right. Sure, some are more
trivial, one can just increase the revision, send it to the CI and
merge it if it passes. But please note that people have the right to
"real life" beyond MacPorts as well.

While some automatism is possible, new version often need manual
intervention: sometimes upstream changes the build system, sometimes
they break it for us, sometimes they come with unacceptable new bugs,
maybe dependent packages break, maybe the patches no longer apply or
new patches are needed, sometimes location of the upstream project
changes, ...

> all those 20k+ packages
> are sure not updated manually by a handful of individuals on explicit
> request of a user, right?

Not all of them are updated on user request, but all of them are
updated manually. Often tools are used to get simple changes done, but
it's still done by people manually running the tools.

We are also always happy if someone can help us write and improve the
tooling to be able to do this more efficiently.

And yes, the maintainer in question has 23k+ commits (data taken from
openhub, it might be more depending on what you count, and this
doesn't include all other contributions made, any rebased changes
etc). All of them were done more or less manually.
(Just for comparison: our competitor's most active contributor has
35k+ commits according to openhub. And no, that's still not a robot.
Their robot has 140k+.)

> in the case at hand, the ksh93 "releases" reside as tarballs at
>
> https://github.com/att/ast/releases
>
> but this obviously is known to the package maintainer, I'd say... so why
> would a PR be in order?

- maintainer might be offline for a while

- while he might available, he might have other more important task
(including his real life!) that he needs done first

- if someone prepares a PR, the maintainer may look at it, and based
on CI results and experience with that particular software, and
depending on the extent to which the author has already tested the
changes, maybe decide to just click on the merge button while waiting
at a traffic light with his phone, greatly speeding up the process

- if the maintainer is not even online or otherwise available for a
certain amount of time, others may merge the changes

> and apart the pain caused by having to deal with git(hub) in the first
> place ;): in my view, the whole point of a descent package management
> system (which macports sure is these days more than ever) is that it
> frees the user from having to deal with the "low level" stuff while
> enabling him to just use the software he needs/wants.

Yes. Any decent software should be of great help to users ... provided
the developers spent an enormous amount of effort to make that
software great.

The whole point of going to a restaurant is to have a tasty dinner
served without the need to spend time cooking yourself. But that
assumes that you have some competent people working there, who put a
lot of effort into both learning and preparing your meal. Except in
this case you have volunteers working in the kitchen after-shifts
(when they come back from their regular paying jobs in the late
evening) and you don't pay a dime to eat there. If your expertise can
enable the kitchen to prepare better food, by providing better
ingredients, better tools, better knowledge ...

> so while I
> understand the purpose of a bug tracker it seems already somewhat
> "wrong" to me that macports users need to have a github account in order
> to submit bug reports. led alone PRs... is it only me?

Our Trac wasn't linked to GitHub until a few years ago, but that meant
that anyone wanting to submit a bug report had to create "yet another"
account, remember yet another password, and that spammers had an easy
job as well.

Think from the following perspective. If you want a new shell in
MacPorts, all you need to do is change a few lines, submit them for
review, and a few days later it may be included for everyone. If you
want a new version of the shell in macOS ... well, I guess I should
say "good luck" until maybe a year or two later, or maybe simply
never.

Someone has to do the work. This can either be a busy maintainer, or
random users passing by who happen to have a genuine interest in
getting the software fixed, and a bit of extra time to test.

(1) Submitting a bug report is already valuable help which takes time
(and is considered work).
(2) If you manage to update the port locally and test it, you can also
send a patch to the mailing list (so no need to create a github
account), which will be even more helpful (including the feedback
whether it solved the problem you are experiencing). I can probably
attempt an update myself, but I have no idea how to check if some
software X that I'm not using myself is even working, to start with,
and if I break something, I'll create a worse situation.
(3) Submitting a PR is of ultimate help and the best guarantee to end
up with the code getting merged much faster than having to wait for
maintainer to have a longer free time slot to do all the changes and
testing.

Mojca