Port maintainers don't look there. Proper way is to submit patches through this bugzilla.
As far as I know, GitHub does not have a mechanism for completely disabling pull requests. I think just about everything else can be disabled. I'd love to be told that's wrong.
I feel that GitHub might not be very willing to provide this feature, even it might not be hard for them, because this is somehow an opposite direction from what they want their users do. I think one possible and might be more practical way is setting up some bots or github action to automatically direct the contributors to the right place, and even migrating the content to a better place, which, for now, would be bugzilla and phabricator. For example: https://github.com/torvalds/linux/pull/805#issuecomment-593375542= When creating the freebsd-git user (https://github.com/freebsd-git) to push the commits, I also registered another freebsd-bot user (https://github.com/freebsd-bot) to prepare for this kind of usage. Maybe it's time to resume this work. We can start from surveying how others are doing currently.
If maintainers don't look there, it should be possible to write a bot that notifies them accordingly, in fact, that could be rather trivial to write. There are currently merge-able PRs in the queue that would be easy to push into our repo, if someone was willing to test them. I find it a nicer and lower-friction way than to download patches from Bugzilla.
(In reply to Ulrich Spörlein from comment #3) In order to test submitted patches one needs to download them first. It requires some effort with both GH and Bugzilla. In my experience, no more than 10% of submitted patches can be merged without changes, so no, just pressing the "Merge" button wouldn't work.
(In reply to Ulrich Spörlein from comment #3) > If maintainers don't look there, it should be possible to write a bot that notifies them accordingly, in fact, that could be rather trivial to write. Oh yes this should be a very good start. And that's exactly the reason we create dev-reviews list used for: https://lists.freebsd.org/subscription/dev-reviews A post to that list when a new PR is created should be fine. I haven't surveyed how to do so, do you have some pointers or PoC of this?
I wasn't implying that you can merge them from the UI, the GH repo is a read-only mirror after all. But the "effort" with GH is so much less compared to wrangling attachments from Bugzilla. Please see https://github.com/bsdimp/freebsd-git-docs/blob/main/pull-request.md, after a one-time setup, you can simply: % git checkout github/pull/422/head % <run poudriere test or whatever, if things are ok, continue> % git checkout main % git rebase|cherry-pick|weapon-of-choice $pull-request-commit That last part differs based on your style of course. And yes, the PR doesn't auto-close once you've pushed it into the upstream repo, so you still need to go to the GH webpage and tell the originator that it was merged and close it. But in theory our "close-a-PR" bot could do it for both Bugzilla PRs and Github PRs. Li-Wen, I have no pointers, sorry. I'd look at what sort of API or PubSub thingy Github offers to see new PRs, or you can simply fetch them all via cron and somehow keep state on what PR heads are "new" and inspect what port they are about and poke their maintainer with instructions on how to fetch/pull them down from GH using the doc I mentioned above.
For people who are not aware of the freebsd-git list: <https://lists.freebsd.org/subscription/freebsd-git> – maybe a better place for some of what's discussed above. Thanks.