Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this community
Frequently after one pull request is merged, multiple other pull requests follow to clean up a problem created by the first PR
Recent example: https://github.com/bitcoin/bitcoin/pull/7957
https://github.com/bitcoin/bitcoin/pull/8164 https://github.com/bitcoin/bitcoin/pull/8171
Normally no real harm is done. Is this no big deal or a sign that more testing should be done before Bitcoin pull requests are merged?
Each pull request usually isn't that big, so it's not hard to look through every line of code. Each pull goes through meticulous testing, in case of any malicious code or an unintended flaw. Why do you think it takes usually more than one month after the pull is made to get added, even though there is alot of discussion in the comments?
I have seen this a lot too. It is a very difficult question to answer as it really depends on the specifics and magnitude of the problem that got merged.
Personally, I think pull requests shouldn't be merged as quickly as they sometimes are as there should be time given for review of even minor changes. The maintainers are in a tricky spot though as sometimes pull requests get no review, are left open for weeks or months and go stale (require rebases). For good reason sometimes maintainers merge pull requests with very little collective review if they deem them low risk.
In an ideal world there would be instant testing and review of every pull request and then the maintainers wouldn't have to make a judgement on what is low risk and not in need of much collective review. But we are not in an ideal world and generally (in my unqualified opinion) I think the maintainers get these judgements right.
The most important thing obviously is to avoid problems making into a release. If problems get resolved in additional pull requests prior to a release it is comparatively less of an issue.
