Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
build.c: Remove g_ptr_array_foreach with gpointer user_data & update HACKING #2270
Aug 29, 2019
1 check passed
Yeah, maybe we should either wait for one Github "approved" or else ping it before merging.
Edit: Alternatively, we could say that if a PR has been submitted for over N days and has no Github "requested changes" on it, it's safe to merge. IOW, if you have an issue with a PR but no time to do a proper review, do a "requested changes" review with a short comment explaining as much.
For this PR, I only did a superficial review of the code (hence no "approved"), but any specific issues I had were resolved and I agree with the changes in principle.
As Matthew said, the discussion was about foreach_, which the merged code no longer used.
It seemed Matthew agreed with the change because he suggested wording for the HACKING file. He hadn't commented on the build.c change, but as he appeared to support the principle in the HACKING file, the build.c change was enforcing the principle.
BTW, I'm not sure what you mean about 'nominated reviewers'?
You had told me a few months ago to leave pull requests open for at least a week, including a full weekend, before merging (I would still wait longer for any change likely to need discussion). I hadn't seen any new criteria for merging since then. Reverting should only be done if there's a commit that causes more harm than good, and the author is not able to fix it speedily.
Sounds good, but for simple changes N should be low. Sometimes there's a pull that causes merge conflicts on other pulls (not the case for this one though), then it's pragmatic to merge quite soon. Otherwise pulls are harder to review because they include dependent commits too.
It's good to usually merge stuff without waiting too long, particularly when follow-up work is likely. In master those changes will likely get tested more as more people will use them. If there's a problem, we can revert. I think this project has been too hesitant in the years I was away to merge code, work from developers can end up sitting in the review queue indefinitely. Maybe none of us will ever get around to reviewing it, despite the changes being very useful and working. In those cases, we should merge if the code is well written and the changes are wanted even if we won't test them ourselves, assuming the author says they've tested them adequately.
I think a comment 'please wait for my review' should be enough, unless there are lots of other comments also.
If there is a plan for a sequence of steps then that should be notified in an issue, possibly with a set of checkboxes listing the steps so they can be checked off as each PR on the process happens. But you can't expect people to read your mind about what your future plans for follow up are.
Those of us here with English as a first language need to remember that although we have the same language, we don't have the same technical, professional, experience or cultural backgrounds. So we may speak alike, but we do not think alike. That means we need to put more effort into communicating our background reasoning and future intentions and not assume others will understand automatically and will come to the same conclusion about how a specific PR should be approached.
For instance, concern has been expressed that some PRs are rearranging the deckchairs on the titanic and not achieving any substantive improvement. Whilst I defend your right to align deckchairs, it would be good to know if their is a master plan behind it or just an itchy spot to scratch.