Question about port maintainer timeout

POSIX.1 said:
And the one you are hinting to is used by portscout:
Click to expand...
Portscout is a tool that keeps track of upstream version updates and notifies the maintainer. Unmaintained ports have freebsd-ports mailing list set as maintainer. So any PRs regarding those ports get posted on the mailing list. Where ports management, port commiters and other maintainers discuss changes, provide help, etc.
 
IIUC, maintainer timeout of PRs for ports are basically 2weeks and any committer can pick it and commit, except for the cases that the change need explicit approval of portmgr and/or secteam. In these cases, "maintainer timeout" is usually recorded in commit messages.
 
T-Aoki said:
IIUC, maintainer timeout of PRs for ports are basically 2weeks and any committer can pick it and commit, ...
Click to expand...
... but often it does not get picked by other committers. As "maintainer timeout" is searchable you can see a long list of documented maintainer timeouts still open for a long time period:

Bug List

bugs.freebsd.org bugs.freebsd.org

As an example take this PR 286479 where our valued member zirias@ is the maintainer. Maybe he wants to explain us why there is not even a single feedback?
 
POSIX.1 said:
... but often it does not get picked by other committers. As "maintainer timeout" is searchable you can see a long list of documented maintainer timeouts still open for a long time period:
Click to expand...
Would be because it's not auto-assigned. So committers doesn't know whether or not other committer is already working on it or not, thus, don't start to work on. And also, they don't know whether the PR is still actually persists or not (as in some cases, updates by any other PR fixes it).

This is why posting to freebsd-ports ML is often helpful. If any committer having time noticed it, it could be handled.
And why sending direct email to the maintainer is not always helpful.
Not all maintainers are committers, thus, cannot commit it by themselves need committer to commit. There should be cases that a maintainer is looking for a committer for approved patch.

Another concern would be the complexities. Any too complexed-to-confirm problems/patches takes long time to read/build and test, make it delay long.

And in some limited cases, PRs are racy.

For example that recently resolved, x11/nvidia-driver* shared single distinfo, making them racy. If, for example, PRs for x11/nvidia-driver and x11/nvidia-driver-470 arose at the same time and both including distfile updates, both need to touch the exactly same file, x11/nvidia-driver/distinfo (and in some cases, both want x11/nvidia-driver/Makefile), thus, racy.

This is significantly reduced by dividing distinfo into per-port basis.
There are still races if both needs something to do in x11/nvidia-driver/Makefile, though, it would be not so often.
 
Ah, "Racy" as in "Race Conditions"... ;) That wikipedia link offers a nice explanation for the situation that T-Aoki is talking about. Same logical pattern.

A few years back, we did have someone who posted a few "racy" wallpapers :P. Those have a very different meaning to the term "racy". Googling that last one is left as an exercise for the reader.
 
T-Aoki said:
Would be because it's not auto-assigned.
Click to expand...
To be auto-assigned, Bugzilla PRs need to start with "<category>/<portname>". Then Bugzilla sends email and perhaps changes the assignee (if they are @FreeBSD.org).

If anyone sees ones that aren't, just email bugmeister@FreeBSD.org, and we will manually fix them. PRs come in so fast that it is hard to catch them all.

And also, over the weekend I poked at a few PRs that had "no maintainer response in more than 6 months". For most of them I just asked for feedback, but in a few cases I just went ahead and took action. It's slow work, but it can be done.
 
  • Like
Reactions: cy@
linimon@ said:
To be auto-assigned, Bugzilla PRs need to start with "<category>/<portname>". Then Bugzilla sends email and perhaps changes the assignee (if they are @FreeBSD.org).

If anyone sees ones that aren't, just email bugmeister@FreeBSD.org, and we will manually fix them. PRs come in so fast that it is hard to catch them all.

And also, over the weekend I poked at a few PRs that had "no maintainer response in more than 6 months". For most of them I just asked for feedback, but in a few cases I just went ahead and took action. It's slow work, but it can be done.
Click to expand...
Ah, sorry for confusing you.
I meant, "no committer is auto-assigned on maintainer timeout".
 
You must log in or register to reply here.
Back
Top