stable-8.0.1 re-tagging?

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

Re: stable-8.0.1 re-tagging?

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

Tue, 30 May 2023 11:15:31 +0300 Michael Tokarev <mjt@tls.msk.ru>:

> 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 man page of git-tag is very clear on this topic IMO. Go for v8.0.2.

Olaf

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: stable-8.0.1 re-tagging?

[Michael Tokarev]

30.05.2023 11:28, Olaf Hering wrote:
> Tue, 30 May 2023 11:15:31 +0300 Michael Tokarev <mjt@tls.msk.ru>:
> 
>> 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 man page of git-tag is very clear on this topic IMO. Go for v8.0.2.

That's actually a very good one Olaf.  The git-tag manpage has a very good
explanation. It was my quiet gut feeling too, but a (non-existing) opportunity
to "just fix it all automagically" was tempting :)

Yeah, it's better to go with 8.0.2 here.

Thanks,

/mjt

Re: stable-8.0.1 re-tagging?

[Thomas Huth]

On 30/05/2023 10.15, Michael Tokarev wrote:
> 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. 
...
> 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.

FYI, only a subset of the iotests are run during "make check" since some of 
them do not work reliable in all environments (e.g. non-Linux systems). To 
be more precise, only the ones marked with the "auto" group are run during 
"make check", and test 307 does not have the "auto" label, thus it is not 
run in the CI.

  HTH,
   Thomas