3 ms·

I agree completely about revisions on PRs. Also, proposed patches often spawn much broader technical discussions that are much better on a mailing list than on

I agree completely about revisions on PRs. Also, proposed patches often spawn much broader technical discussions that are much better on a mailing list than on a random commit (that will likely become unreachable later since it's not going to be accepted). Nothing beats the archival quality of mailing lists and if you start your code review there, you never need to make the choice to "move" a discussion from GitHub to a mailing list. The problem is that mailing list review requires a lot of discipline and some popular MUAs make it especially painful. The value of PRs and other models is that they degrade more gracefully to lack of experience/discipline, and (perhaps) to casual involvement (subscribing to mailing lists with delivery turned off is fine as long as there is a convention to Cc people that are likely interested in a specific change; not many people know about subscribe-without-delivery).

ak217 13y ago
> proposed patches often spawn much broader technical discussions that are much better on a mailing list than on a random commit (that will likely become unreachable later since it's not going to be accepted) PRs are also issues, and I vastly prefer GitHub issues to mailing lists (to each his own, I guess).
- jedbrown 13y ago
  I like inline code comments, especially when the original commits are not well factored. But I find it too common for a discussion starting from a patch to gradually become general and ultimately involve dozens of people that had no interest in the original patch, but care a lot about the general discussion. Sometimes these involve multiple projects, in which case cross-posting to another mailing list makes sense. With GitHub Issues, you generally tag individuals rather than groups of perhaps hundreds of people (most of whom filter on their own criteria). Later, how well does search find the 100-message design discussion starting on a commit in a PR that was later amended and then rejected? And what if you move the repository elsewhere?
- gsnedders 13y ago
  PRs being issues is an issue in an of itself: it tempts one into not opening an issue for the bug the PR is fixing. Then, if the PR is closed, there is no open issue for the underlying bug it was attempting to fix.

ak217 13y ago

> proposed patches often spawn much broader technical discussions that are much better on a mailing list than on a random commit (that will likely become unreachable later since it's not going to be accepted) PRs are also issues, and I vastly prefer GitHub issues to mailing lists (to each his own, I guess).

jedbrown 13y ago
I like inline code comments, especially when the original commits are not well factored. But I find it too common for a discussion starting from a patch to gradually become general and ultimately involve dozens of people that had no interest in the original patch, but care a lot about the general discussion. Sometimes these involve multiple projects, in which case cross-posting to another mailing list makes sense. With GitHub Issues, you generally tag individuals rather than groups of perhaps hundreds of people (most of whom filter on their own criteria). Later, how well does search find the 100-message design discussion starting on a commit in a PR that was later amended and then rejected? And what if you move the repository elsewhere?
gsnedders 13y ago
PRs being issues is an issue in an of itself: it tempts one into not opening an issue for the bug the PR is fixing. Then, if the PR is closed, there is no open issue for the underlying bug it was attempting to fix.