ksh93

[joerg van den hoff]

thanks a lot for all these clarifications. I really was not aware that 
package update is so dependent on manual intervention the macports 
package maintainers. which makes your work even more impressive.

and I am completely aware that it is voluntary work and you are under no 
obligation (or expectation AFAIAC) to "make it work" for the users
according to _their_ rather than your own priorities...

so if your message is that for your side tickets (even for things like 
"please update the package" are less burdensome than this ML, then I 
will comply of course. I was so far under the impression that
tickets are reserved for reporting real malfunctioning of packet 
installs or `ports' bugs proper...

regarding PRs for package updates: is their a procedure guideline how 
this is done properly or do I have to find my way around myself?

best regards,

joerg

On 16.11.19 09:25, Mojca Miklavec wrote:
> 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
>