<HTML><BODY><div class="cl-n32r58iu1c"><div class="mail-quote-collapse"><blockquote style="border-left:1px solid #0857A6;margin:10px;padding:0 0 0 10px">Current distance between fixes and main is about 13739 revisions. (not<br>counting the 23 fpcbuild revisions, and the work that needs to be done<br>for docs). Of course a MR can be more commits/revisions, but rarely more<br>than 20. So 100 merge requests is at most 2000, and that is already a<br>stretch, both wrt commits/mMR and that that already assumes that are<br>most are viable to merge and will be eventually merged.</blockquote></div></div><div> </div><div><div class="cl-n32r58iu1c"><blockquote style="border-left:1px solid #0857A6;margin:10px;padding:0 0 0 10px"><div><div>You make a fair empirical point, and I genuinely do not know the</div><div>answer either. It would be worth someone running that comparison</div><div>before we treat the MR backlog as the primary symptom.</div></div></blockquote></div></div><div>This is really interesting! I analyzed the open MRs and posted the results on the bug tracker (GitLab allows for good formatting/linking/editing): <a href="https://gitlab.com/freepascal.org/fpc/source/-/work_items/41722">https://gitlab.com/freepascal.org/fpc/source/-/work_items/41722</a></div><div><br>The first rows of the table are very small MRs that can be reviewed and resolved quickly. This could potentially help close a dozen or so MRs at once.</div><div><br>The table also clearly shows "abnormally" large and empty MRs — I've already submitted comments on some of them (looks like a merge/rebase error).</div><div> </div><div>Later, I'll be able to compare their total size with the difference between the main/fixes branches. Frankly, I don't think "commit" is a good unit of measurement, so I counted the number of "changed lines". But the number of commits could also be taken into account.</div></BODY></HTML>