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?
