stable-8.0.1 re-tagging?

[Michael Tokarev]

Hi!

Yesterday I pushed v8.0.1 tag for 8.0.1 stable qemu release, but in the
process of publishing it, Michael Roth discovered a regression in iotest
which we all overlooked when initial patch has been applied to master.

The commit in question is this one:

commit de79b52604e43fdeba6cee4f5af600b62169f2d2
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Tue May 2 17:11:19 2023 -0400

    block/export: call blk_set_dev_ops(blk, NULL, NULL)

It caused iotest 307 to fail, - qemu failed with Sig11.  This has been
fixed by this commit:

commit a184563778f2b8970eb93291f08108e66432a575
Author: Kevin Wolf <kwolf@redhat.com>
Date:   Wed May 10 22:35:55 2023 +0200

    block/export: Fix null pointer dereference in error path

I applied it on top of other 8.0.1 changes, things are now working fine.

The question now is: should we re-tag v8.0.1, or should I push
v8.0.2 instead (with 8.0.1 not being released and published
on the download page)?

This is the first time something like this happens, it seems: a bug
in release is discovered between pushing the tag and publishing
things, so we haven't been in this situation before, when the tag
is there but the release should not happen.

I removed the tag for the bad release from gitlab.org qemu repository, -
I thought the permissions wont let me do that, but it just worked.
The tag still exists locally and on my clone of qemu repository on
gitlab.

So I can restore v8.0.1 and push v8.0.2, or I can re-push v8.0.1 for
the new commit (which would be one extra commit after "Updating version
for v8.0.1").

I'm for creating new v8.0.1 tag for the new commit.  But I'd like to
hear opinions of others on this matter, since this is an important
process which definitely should be public.

The reason for this failure is my misunderstanding: for some reason
I was sure whole range of tests is done within the CI infrastructure,
but it turned out even basic iotests aren't run.  It's interesting that
I did run iotests locally, just to become more famliar with that stuff,
the day before I cherry-picked the bad commit in question :)

And another lesson for me to learn, - actually 2 - first is to listen
to myself, since my inner self did think about running more complete
checks after a bunch of block-io changes which I picked up, but I didn't
think about that with enough attention. And second is to verify whatever
I "think" is true, instead of relying on own assumptions, - here, I was
sure iotests are run within CI infrastructure, but nothing really indicates
this is the case.

Thanks!

/mjt