Re: please try to avoid sending pullreqs late on release-candidate day

[Kevin Wolf <kwolf@redhat.com>]

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