<p>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?</p>

CC BY-SA 3.0
2016-08-22T21:33:15.723Z
2016-08-22T21:33:15.723Z
Whyte the Weeabear
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2020-12-30T13:07:34.847Z
2020-12-30T13:12:48.733Z
2020-12-30T13:12:48.733Z
Michael Folkson
<p>Frequently after one pull request is merged, multiple other pull requests follow to clean up a problem created by the first PR</p>

<p>Recent example:
<a href="https://github.com/bitcoin/bitcoin/pull/7957" rel="nofollow">https://github.com/bitcoin/bitcoin/pull/7957</a></p>

<p><a href="https://github.com/bitcoin/bitcoin/pull/8164" rel="nofollow">https://github.com/bitcoin/bitcoin/pull/8164</a>
<a href="https://github.com/bitcoin/bitcoin/pull/8171" rel="nofollow">https://github.com/bitcoin/bitcoin/pull/8171</a></p>

<p>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?</p>

<bitcoin-core-development><bitcoincore-review>
How much testing is done on each pull request before it is merged?
John
# How much testing is done on each pull request before it is merged?

(Asked by: username_0 on 2016-06-16)

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?

**Tags:** bitcoin-core-development, bitcoincore-review


---

## 2 answers

### Answer by username_1 on 2016-08-22. Score: 2 | Accepted answer

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?


---

### Answer by username_2 on 2020-12-30. Score: 0

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.


---

