Specific to ticket filing: https://guide.macports.org/#project.tickets <https://guide.macports.org/#project.tickets>
and for more details for the ticket filing itself, rather than bug confirmation/description (not applicable to an update, perhaps): https://guide.macports.org/#project.tickets.guidelines <https://guide.macports.org/#project.tickets.guidelines> > On Nov 16, 2019, at 07:55, Ryan Schmidt <[email protected]> wrote: > > > > On Nov 16, 2019, at 06:49, joerg van den hoff wrote: > >> 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? > > If you want to ask for a port to be updated, filing a ticket is better than > mentioning it on the mailing list, because tickets can be more easily > searched and assigned to people. Use the ticket type "update" and put the > maintainer's email or GitHub handle in the Cc field. > > If you want to help us out and try to do the update yourself and submit it, > that's great. > > For help with editing portfiles, our guide should cover the basics: > https://guide.macports.org > > For help working with git, including making a pull request, we have: > https://trac.macports.org/wiki/WorkingWithGit ; there's also lots of other > non-MacPorts-specific advice out there on the Internet for working with git. > > If git is too troublesome, it's also fine to attach a diff of your work to a > ticket (though inevitably someone will reply recommending you submit a pull > request instead). > >
