How to work around the Merge / Pull request Bottleneck?

What is the current process or strategy by which gets decided when a pull request gets merged or pushed to the build / test runner?

From my pov, it seems like the only way for a PR to get merged is to catch a maintainers attention (I assume fixing an issue related to a milestone), otherwise you land in the general “maybe-later”-pile.

This is generally fine considering zfs limited time and funding, but causes the the Pile of PR’s to grow, with out of date branches, that are unaware of each other.

How can we actually “push” non-milestone or enhancement / quality of life PR’s without burdening the zfs staff?

Should every non-maintainer PR be linked to an issue and be closed if it does not?
Should every issue raised this way be argued for intensely?
Are we just too lazy in documentating our code and intent for them to be merged easier?
Are non-milestone issues actually not that important, regardless of how they may look to the contributor?

What do you think?

From my experience I’d say that your time is indeed best spent working on issues that have already been triaged and are ideally part of an upcoming milestone, especially if you’re a new contributor. Beyond that building a certain rapport definitely helps, the more you contribute the more likely your PRs will be looked at (I realize this is a bit of a chicken-and-egg problem, some persistance is required).

I’d encourage you to join the ZSF Zulip channel, if you have an idea and ideally a concrete use-case you can talk about it there and ask for help implementing it if needed. You can also ask for feedback on your current progress which will facilitate reviewing your code later. If you already have a PR up that’s passing CI and is ready for review you can also send a friendly reminder on Zulip up to once a day for it to be looked at.

WRT the PR itself, having a short text that describes the changes you’ve made, a couple of tests to prove that the changes actually work and a reasonably clean and easily traceable commit history with meaningful commit messages of course also helps to make your PR easier to review.

Unfortunately there will always be a remaining chance that no one will find the time to review your PR before merge conflicts start piling up, no matter how high quality it is. That’s just the reality of the resources the core team has as of now.

Best of luck on your PR!

4 Likes