triplus wrote: ↑
Sun Apr 19, 2020 12:49 pm
...As PR count would only grow during such time frame and after we would need to take care of 300 PRs.
P.S. After i guess we need to discuss on how to proceed. As volume of PRs and volume of massive code changes is becoming a bit unmanageable. Stressing the upstream in such way over the longer periods of time can start to have negative effects. What can we do to mitigate that?
The number of pending PR doesn't matter. Each author should know the reason he or she opened that pull request. We have to assume each pull request is made with the best intentions to improve the software, so whether it is merged before a certain date, in one release or another, is not important, unless it is made to correct significant bugs in the code.
Each author should thoroughly comment their pull requests in order to really explain why that pull request is being made. I try to do that, even if it's a bit boring and verbose. The other thing is learning to use the Git system well. In many cases authors add too many commits where they change one thing, and then change it again in the next commit. This makes it a bit difficult to review the code. So authors should try to make their commits as compact as possible, and squash certain commits together, so that review is easy to do, not only by the administrators but also by other users interested in the changes.
A personal recommendation. I've been merging various pull requests lately, and I've had to edit and rebase many times, so I've noticed that this becomes difficult when a single branch has too many commits. So I propose a soft rule that a single pull request shouldn't introduce more than 10 commits at the same time. If we need to add more commits, then these should come in a second pull request that follows from the first. Say, pull request #5000 with 10 commits, and Part 2 in #5001 with 8 commits. Then we can review the first one and then the second one more easily. Also, if we need to change the history of some commits, and then rebase, this can be done more easily.