On Sun, 11 Oct 2015 13:02:50 +0200 Manuel Rüger <mr...@gentoo.org> wrote:
> It might be also worth to think about limiting the feedback to the > actual patch that is included in a pull request or whatever is used as > transport media. > I have the feeling that some pull requests are accepted, after the > package has been refactored or mistakes or deprecated styles former > maintainers applied have been fixed. I'm not sure if new contributors > like that kind of extra work to get their pull requests accepted or > feel overloaded by the mass of comments some ancient ebuilds may > produce. Nit-picking over mistakes or old standards that the contributor didn't even add has proven to be quite frustrating. I feel this largely comes about from the fact that new ebuild revisions appear in a diff as entirely new content and there's no quick way, at least on GitHub, to compare it against the previous revision that still exists. It also seems a tad wasteful as I don't think git will optimize around the fact that this new revision may have as little as one changed character. This is where Subversion has the upper-hand as it explicitly supports copying as well as moving. I tried to think of some clever way around this but came up empty. :( I think we should therefore encourage reviewers to not just look at the raw diff but also compare against the previous revision to see what has really changed. While mistakes and old standards should be corrected, if they have already been present, and possibly even stable, for months or years then they're probably not doing that much harm. We should allow improvements to be done iteratively. -- James Le Cuirot (chewi) Gentoo Linux Developer
pgpih6fMbyp9B.pgp
Description: OpenPGP digital signature
