Am 21.07.2020 um 17:56 hat Peter Maydell geschrieben: > It is not helpful if everybody sends their pullrequests late > on the Tuesday afternoon, as there just isn't enough time in the > day to merge test and apply them all before I have to cut the tag. > Please, if you can, try to send pullrequests earlier, eg Monday.
I sent the majority of my fixes for -rc1 on Friday, not the least to give us some time in case we get a testing failure. However, the earlier you send the pull request, the greater the chance that you get some new patches after the pull request. In this case, the patches were only ready Tuesday afternoon, so even sending on Monday instead of Friday wouldn't have helped. The alternative would have been letting them wait for -rc2. I suppose you can always says "too late" and make that decision for me, but I wouldn't want to unnecessarily move things to a later RC. Do you think we shouldn't send a pull request in case of doubt? So given that we _will_ have some late patches, what can we do to improve the situation? Maybe I could send the pull request before testing it to save some time. Your tests will take a while anyway, so if my own testing fails (e.g. for the parts of iotests that you don't test), I would still have time to NACK my own pull request. This wouldn't buy us more than an hour at most and could lead to wasted testing effort on your side (which is exactly the resource we want to save). Can you test multiple pull requests at once? The Tuesday ones tend to be small (between 1 and 3 patches was what I saw yesterday), so they should be much less likely to fail than large pull requests. If you test two pull requests together and it fails so you have to retest one of them in isolation, you still haven't really lost time compared to testing both individually. And if it succeeds, you cut the testing time in half. Kevin
