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
