Speaking of technical stuff… same criticism go towards Microsoft GitHub. Unnecessary social features, search doesn’t work if you’re not authenticated, can’t participate without an account, stuffed with upsells (with the latest being an ad for Microsoft GitHub copilot inside the code view), where the Copilot product is sold back to the users who worked (often for free) to create the code to train it, pushes to use Sponsors so Microsoft can take their cut of donations, custom proprietary Markdown fork that isn’t compatible with other platforms …and to top it off, the pull request model straight-up doesn’t scale for a lot of projects but it’s the only option unless the maintainers consciously decide to host another tool or mailing list outside the Microsoft GitHub forge which defeats the point of even using the code forge product.
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.
Speaking of technical stuff… same criticism go towards Microsoft GitHub. Unnecessary social features, search doesn’t work if you’re not authenticated, can’t participate without an account, stuffed with upsells (with the latest being an ad for Microsoft GitHub copilot inside the code view), where the Copilot product is sold back to the users who worked (often for free) to create the code to train it, pushes to use Sponsors so Microsoft can take their cut of donations, custom proprietary Markdown fork that isn’t compatible with other platforms …and to top it off, the pull request model straight-up doesn’t scale for a lot of projects but it’s the only option unless the maintainers consciously decide to host another tool or mailing list outside the Microsoft GitHub forge which defeats the point of even using the code forge product.
Very interesting: I didn’t know all this about GitHub ! Could you please share some refs about the pull request model not scaling up ?
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.