Created attachment 227358 [details]
"git diff" to update the port
- update 0.14_2 -> 0.15
- request maintainership as Cory R. King seems to be absent for long
- add LICENSE
- add NO_ARCH
- "portlint -AC" says: looks fine.
- "portclippy Makefile" is happy.
- "portfmt -D Makefile" is happy.
- Tested with:
- built-in perl tests in a clean poudriere jail say: PASS.
Why did you take maintainership and removed actual maintainer firstname.lastname@example.org?
To do that happens it must be a maintainer timeout > 3 months and do a maintainer reset first.
We will need to wait for maintainer approval first and if he not respond in > 2 weeks then I can commit this update but I cannot pass maintainership to you.
Could you please update patch?
Created attachment 227386 [details]
"git diff" to update the port
Please find a new patch w/o m-ship transfer.
Please note, that I did not take m-ship, but just requested it,
because this port stays for years w/o proper m-ship.
Requesting of m-ship has been my courtesy for the community.
Now that you deny it, the community stays with virtually
unmaintained port, which are way too many in the tree.
(In reply to Sergei Vyshenski from comment #2)
I've checked some of actual maintainer ports and there is no activity for some time now.
The right thing to do is to create a PR for maintainer reset and not only for this port but for all port he maintains so other people can take a fresh maintainership.
I didn't deny maintainer transfer, I'm only saying that we need to reset it first so that port can be adopted again.
I will not wait for > 2 weeks timeout to update it.
I will return this port to pool again while I can get some help from other more experienced committers do a maintainer reset.
just a reference, the ports maintained by actual maintainer:
(In reply to Nuno Teixeira from comment #3)
Thank you for your concern.
Let me clarify.
Maybe here we have an example of a bigger problem.
I do not have a goal to collect unattended ports.
I am just concerned about updating dependencies for my main port
It has many hundreds of dependencies
(if you count test_dependecies, there are around a thousand of them).
And often it is essential that these dependencies be up to date --
for correct work of the named port.
Some maintainers of these dependencies have been not seen
in the FreeBSD project for 10-15 years.
Often when I try to update a such, I takes months.
With time patches turn obsolete, I have to recreate them.
IMHO this practice is strange and even humiliating.
And maybe it is worth reconsidering.
(In reply to Sergei Vyshenski from comment #4)
You are complete right.
I'm askisg freebsd-ports mailing to see if a more experiened committer takes a look. If it fails I will try a review in phabricator with some luck with my former mentors.
A commit in branch main references this bug:
Author: Sergei Vyshenski <email@example.com>
AuthorDate: 2021-08-24 22:25:35 +0000
Commit: Nuno Teixeira <eduardo@FreeBSD.org>
CommitDate: 2021-08-24 22:37:47 +0000
devel/p5-Params-Coerce: Update to 0.15, maintainer reset
* Submitter takes maintainership.
* devel/p5-Params-Coerce: maintainer reset
Many consecutive timeouts. We thank coryking for all his efforts and
hope to see him back in the future.
Approved by: maintainer timeout (firstname.lastname@example.org > 2 months)
devel/p5-Params-Coerce/Makefile | 10 +++++++---
devel/p5-Params-Coerce/distinfo | 5 +++--
2 files changed, 10 insertions(+), 5 deletions(-)
If you have other ports from email@example.com as maintainer that you like to update please mention this PR to a committer. This PR is a maintainer reset/submiter becomes maintainer.
The best thing that I or other committer should do is to investigate all ports from firstname.lastname@example.org and prepare a reset maintainership for that ports.
Thank you very much.
No, other ports of coryking are outside of my field.
But maybe you could have a look on some of my PRs with similar problem from another maintainer,
Jun Kuriyama email@example.com,
who is absent for very very long):