4 ms·
But how is emailing different from something like eg. Gerrit or pull requests. Ultimately, it's always the maintainers who get to decide what gets into the repo
by chopin 9y ago
But how is emailing different from something like eg. Gerrit or pull requests. Ultimately, it's always the maintainers who get to decide what gets into the repo.
What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
- claudex 9y agoYou can allow multiple person to accept a pull request. So you don't have "a" maintainer but some.
- bri3d 9y agoI think your sibling post is similar in sentiment and it comes down to transparency. In the "patches-to-a-list" model, there's no running status page or record of exactly what patches were rejected or ignored, and by whom. Anyone wanting that information would have to go to a lot of work parsing, searching, and analyzing the mailing list. With Gerrit or pull requests, reviewers are clearly assigned and patch states are managed in a centralized dashboard. This makes it a lot easier for external stakeholders (managers, other development staff, etc.) to gain insight into how a team's working and whether or not they're being accepting or effective. And that's why, to me, these kinds of toxic maintainers seem to suffer an extinction event when moved to a more transparent system. The maintainers are the same, but their tool - quietly rejecting patches with little accountability - is taken away from them.