Debug headers received ("block" for new block announcement, "block2" … #8731

…for expected).

This pull request doesn't include the lines in init.cpp mentioning the additional debugs, as these are already mentioned in #8729

Can you please stop opening so many debug-related pull requests at once? This is spammy and annoying for the maintainers.

Please first consider if they are interesting for other people or just for your personal debugging session, and if the former (do explain why!), lump them as multiple commits one pull.

#8733

@MarcoFalke not sure why this has been closed. #8733 was opened as people on the IRC channel had requested a better understanding of the overall scope of the pull requests which that pull attempted to answer. I was not expecting #8733 to be merged given the number of commits it contains and therefore was expecting that it was the smaller pull requests which would have been preferred to be merged.

Some guidance on how to get these changes merged would be appreciated as I did just spend about 3 days rebasing them all after a recent merge broke most of them. #8733 explains the thinking behind them hopefully and the value I see them as having.

@laanwj Apologies. I was not sure how best to proceed and originally thought that a pull request with 20 commits would be more overwhelming than having a number of smaller pull requests. I will re-read the contribution guidelines as perhaps I overlooked this recommendation.

@laanwj I have just re-read the contribution guidelines. They say "Please also avoid super pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult." - wihich is what I was trying to avoid until I was advised otherwise. Is the contribution still correct? I am unsure without clarification of this apparent contradiction how to proceed in the future, or indeed what is considered "too much" since this is a subjective term

@rebroad On the topic of "super pull requests": Take a look at #6265, which is without doubt useful and should have been merged. However, there was too much code and it was impossible to review and make sure that our quality standards are met. Keep in mind that more code increases the likelihood of merge conflicts, which need to be solved and thus invalidate any review that was done up to this point.

Usually it makes sense to split pull requests into topics (we use labels to indicate different modules, etc) and then make clear what the motivation for the pull is and include it in the pull request. E.g. 8501 introduces a new module and exposes some data on the rpc interface. 8550 builds on top of that and introduces new functionality to the gui.

For your "granular debug" pull request(s), often, the motivation for individual commits is not clear and it could be argued (by some) that the exact opposite of what the commit tries to achieve should be done. Trivial commits which will result in a lot of discussion but do not solve an open issue (https://github.com/bitcoin/bitcoin/issues) are usually considered waste of review time and the pulls will be closed.

Also, seeing a bunch of "debug <some number>" pulls being opened and then some of them fail the travis compile step (which indicates you most likely didn't try to compile them on your own) does not help to attract reviewers.

@MarcoFalke Thanks for the useful feedback. Much appreciated. I will make a note to look at the open issues more often, although I could easily create an issue prior to creating the pull request if this would help. I know I've submitted pulls in the past that didn't compile, and I've revised my procedure to reduce this likelihood. All the commits were tested before I raised them in the last 24 hours, and although travis reported failures, it was only on certain architectures - I have yet to understand why this happens!