Re: [PATCH v3 0/2] qemu-img: map: implement support for compressed clusters

[Peter Maydell]

On Fri, 22 Sept 2023 at 15:28, Eric Blake <eblake@redhat.com> 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 <qemu-block@nongnu.org>   <--------
> > > > 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 <qemu-block@nongnu.org>   <--------
> > > > 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 qemu-devel@nongnu.org, because that's
the only case we ran into previously.

# Check whether any authors needs to be corrected after SPF rewrites
if git shortlog --author=qemu-devel@nongnu.org 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