On Fri, 22 Sept 2023 at 15:28, Eric Blake <[email protected]> wrote: > > On Fri, Sep 22, 2023 at 12:10:45PM +0200, Kevin Wolf wrote: > > > > > > In the patches applied to master something went wrong and my email isn't > > > displayed correctly: > > > > > > > commit 2848289168fbbd9a6855c84ec8fde8929a2b042b > > > > Author: Andrey Drobyshev via <[email protected]> <-------- > > > > Date: Fri Sep 8 00:02:25 2023 +0300 > > > > > > > > block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status() > > > > > > > commit 52b10c9c0c68e90f9503ba578f2eaf8975c1977f > > > > Author: Andrey Drobyshev via <[email protected]> <-------- > > > > Date: Fri Sep 8 00:02:26 2023 +0300 > > > > > > > > qemu-img: map: report compressed data blocks > > > > > > There's probably no way to fix that in master, but just giving you a > > > heads-up for maybe there's a bug in your scripts. > > > > Yes, too late to fix it in master. I would have to notice this earlier > > and then fix it manually. > > If I recall, Peter had scripts that would automatically reject pull > requests that have this issue. I don't know if there is a technical > reason why they can't be made part of our CI engine, vs. having to be > copied over to every other developer that also takes on a release > manager role.
Yes, but they only look for [email protected], because that's the only case we ran into previously. # Check whether any authors needs to be corrected after SPF rewrites if git shortlog [email protected] master..staging | grep .; then echo "ERROR: pull request includes commits attributed to list" exit 1 fi I'm pretty sure there's no particular reason that couldn't be handled in a CI job; it's just historical reasons that it happens to be in the apply-pullreq script. (Though one advantage of it being in the script is that you get the failure instantly rather than it kicking off the CI jobs, costing CI minutes and taking a long time to tell you the result.) The other checks currently done in apply-pullreq are: * are we trying to merge after a release and before doing the "reopen development for next QEMU version" commit ? * is this really a signed git tag ? * are there any git submodule changes (this is only a warning, to prompt eyeballing the pullreq to check the submodule update is intended and not somebody accidentally reverting a recent submodule change when they rebased an unrelated commit) * a heuristic looking for mangled UTF-8 in reviewed-by etc tags https://git.linaro.org/people/pmaydell/misc-scripts.git/tree/apply-pullreq#n95 (Someday I should try to get this script into the QEMU tree.) thanks -- PMM
