Re: [Qemu-devel] [PATCH v7 2/9] qemu-binfmt-conf.sh: make opts -p and -c boolean

[Unai Martinez Corral]

2019/3/12 22:56, Eric Blake:

> On 3/12/19 4:39 PM, Unai Martinez Corral wrote:
> > 2019/3/12, Eric Blake:
> >>
> >> On 3/12/19 2:51 PM, Unai Martinez-Corral wrote:
> >>> This patch breaks backward compatibility.
> >>
> >> Is it worth a mention why we don't consider backwards-compatibility for
> >> this script to be very important?
> >
> > 'persistent' is a quite recent feature (8 monts) which seems not to be
> > widely know. See, e.g., the references in
> > https://github.com/umarcor/qus#similar-projects-blog-posts-and-other-references.
>
> This rationale belongs in the commit message.

But there is no rationale here. It is just a style preference, which
is explained in the commit message. Should I add a comment starting
with 'I feel' or 'as far as I am aware' to let others know that there
is no strong argument behind the decission?

> > So I think that it is almost harmless.
>
> I don't know the prospective audience of qemu-binfmt-conf.sh to know if
> it is harmless or not. I'm just trying to make sure that if your commit
> DOES end up breaking something, that whoever ends up bisecting back to
> your commit message has enough information to know whether they need to
> fix their workflow or propose a patch to revert your change.

It is quiet possible that these changes will end up breaking things.
Not only these, but also those in patches 5 and 7. In none of them
have I explained why is backwards-compatibility not important. Better
said, less important than the overall improvement of this patchset.
Since explanations underline the motivation for the changes, I think
that it is implicit why backward compatibility is deemed less
important. Moreover, since all of them are pushed together, I hope
that whoever bisecting back will find that it is a rewrite to improve
consistency; not just an random atomic change.

> I also don't know if this is the sort of change that should go through the
> formal qemu-deprecation.texi policy of two cycles of warnings about
> pending change in behavior before we actually flip the switch, or if it
> is indeed a small enough audience that a formal deprecation is too much
> effort.

I didn't know that the formal deprecation policy applied to changes. I
assumed that maintainers would add these to
https://wiki.qemu.org/ChangeLog/4.0#Incompatible_changes. I am
checking it anyway.

Regarding the two cycles of warnings, since we cannot support both
formats at the same time, does it mean that the patchset should be
divided to two? I.e., one with the fixes/features that can be added
now and a bunch of warnings; and a second one to be merged after two
cycles?