I don’t have any off-hand. But anecdotally I know systems like Gerrit & mailing lists are used for very large and/or very rapid work flows. Nixpkgs has a lot of issues with thousands of open requests, not many reviewers, no way to understand the prioritization, required reviews even if you are the sole maintainer of a small package (so no other user to check the work), separate folks that do merging that are inundated with approved-but-unmerged changes who also… don’t know what to prioritize. This process alone can take weeks (I just now got a merge from 2023-09-29 just merged in) & that was only after having begged twice on the Matrix chat for someone to dedicate the time to do it. Traditionally bigger and/or distributed systems are used to help alleviate or add hierarchy to try to get pushes thru faster.
Another issue pops up with just the review process. You may have seen your favorite $PROG_X just released a new version. You have bumped the version + hash, & submitted a new request. The maintainer tells you all these little nits or stuff about how this package now breaks $PROG_Y & tells you to fix it… like it’s your problem when they are the maintainer. If I were to receive this as an email patch, I would just modify the patchset for you, reply with “Thanks. I made some small adjustments to fit match my style.” or whatever keeping the credit on them. You can amend a users repository iff they allow maintainer access, but adding new remotes is more cumbersome & it’s almost never done as we’ve decided now that the onus should be on contributors rather than helping them ship their changes faster.
I don’t have any off-hand. But anecdotally I know systems like Gerrit & mailing lists are used for very large and/or very rapid work flows. Nixpkgs has a lot of issues with thousands of open requests, not many reviewers, no way to understand the prioritization, required reviews even if you are the sole maintainer of a small package (so no other user to check the work), separate folks that do merging that are inundated with approved-but-unmerged changes who also… don’t know what to prioritize. This process alone can take weeks (I just now got a merge from 2023-09-29 just merged in) & that was only after having begged twice on the Matrix chat for someone to dedicate the time to do it. Traditionally bigger and/or distributed systems are used to help alleviate or add hierarchy to try to get pushes thru faster.
Another issue pops up with just the review process. You may have seen your favorite
$PROG_Xjust released a new version. You have bumped the version + hash, & submitted a new request. The maintainer tells you all these little nits or stuff about how this package now breaks$PROG_Y& tells you to fix it… like it’s your problem when they are the maintainer. If I were to receive this as an email patch, I would just modify the patchset for you, reply with “Thanks. I made some small adjustments to fit match my style.” or whatever keeping the credit on them. You can amend a users repository iff they allow maintainer access, but adding new remotes is more cumbersome & it’s almost never done as we’ve decided now that the onus should be on contributors rather than helping them ship their changes faster.