4 ms·

As somebody who maintains a decent amount of Rust libraries, I do try to keep on top of my PRs, but sometimes Github's notification system makes it easy to forg

by bjz_ 12y ago

As somebody who maintains a decent amount of Rust libraries, I do try to keep on top of my PRs, but sometimes Github's notification system makes it easy to forget that some PRs have been sitting around for a long time. For example if you click on a notification in your inbox, it automatically gets marked as read - you can't keep it around as a reminder. What would be really nice is if you could have some sort of dashboard to let you know the status of your outstanding issues and PRs on all of your repositories - how long they have been open for, whether they are stale or not... etc. It's just too hard to go through each repo individually to check on its health.

masklinn 12y ago
> What would be really nice is if you could have some sort of dashboard to let you know the status of your outstanding issues and PRs on all of your repositories - how long they have been open for, whether they are stale or not... etc. It's just too hard to go through each repo individually to check on its health. There's https://github.com/issues/assigned https://github.com/issues/assigned and https://github.com/pulls/assigned https://github.com/pulls/assigned, kind of. It does require that you assign all outstanding issues, but I don't know of other cross-repository or cross-organisation tools built into github. The other alternative is to use the github API and fetch the precise information you want.
pwg 12y ago
Another issue is that github's "merge a pull request" system is completely broken. Most projects on github, by virtue of being based on git, will have several branches within the repository. The regular contributors to the project will know branch 1 from branch 2 and will submit their PR's against the projects "dev" branch (whatever it happens to be). But irregular contributors, or out of the blue contributors, will invariably choose a branch that is not the projects "dev" branch upon which to base their patch, and then submit their pull request. And for the project receiving the pull request, the github "handle it" interface is all-or-nothing. You either put the patch in, against the branch the requester used, no matter how wrong that branch might have been, or you simply can't merge it via. github's web interface. And if you don't merge it by github's web interface, you can't mark it accepted. Your choices are "accept and merge patch" and "refuse". So there's a very good chance that some number of those outstanding pull requests shown have actually been merged, but were merged by the maintainer pulling a patch out of github manually, and applying the change manually via git to the correct branch and not the branch the submitter picked. And since the patch was in fact merged, poking the github "refuse" button in the web interface would seem wrong, so the outstanding pull request just hangs around, forever, because github can't be told "I did merge this, just outside of your view".

by bjz_ 12y ago

masklinn 12y ago

> What would be really nice is if you could have some sort of dashboard to let you know the status of your outstanding issues and PRs on all of your repositories - how long they have been open for, whether they are stale or not... etc. It's just too hard to go through each repo individually to check on its health. There's https://github.com/issues/assigned https://github.com/issues/assigned and https://github.com/pulls/assigned https://github.com/pulls/assigned, kind of. It does require that you assign all outstanding issues, but I don't know of other cross-repository or cross-organisation tools built into github. The other alternative is to use the github API and fetch the precise information you want.

pwg 12y ago

Another issue is that github's "merge a pull request" system is completely broken. Most projects on github, by virtue of being based on git, will have several branches within the repository. The regular contributors to the project will know branch 1 from branch 2 and will submit their PR's against the projects "dev" branch (whatever it happens to be). But irregular contributors, or out of the blue contributors, will invariably choose a branch that is not the projects "dev" branch upon which to base their patch, and then submit their pull request. And for the project receiving the pull request, the github "handle it" interface is all-or-nothing. You either put the patch in, against the branch the requester used, no matter how wrong that branch might have been, or you simply can't merge it via. github's web interface. And if you don't merge it by github's web interface, you can't mark it accepted. Your choices are "accept and merge patch" and "refuse". So there's a very good chance that some number of those outstanding pull requests shown have actually been merged, but were merged by the maintainer pulling a patch out of github manually, and applying the change manually via git to the correct branch and not the branch the submitter picked. And since the patch was in fact merged, poking the github "refuse" button in the web interface would seem wrong, so the outstanding pull request just hangs around, forever, because github can't be told "I did merge this, just outside of your view".