Libguestfs - Nov 2021 - [virt-v2v RFC wave 2 03/10] convert/windows_virtio: restrict the warning with virtio-win.iso absent

On Sat, Nov 06, 2021 at 04:45:33PM +0100, Laszlo Ersek
wrote:
> On 11/02/21 09:52, Richard W.M. Jones wrote:
> > I hesitate to submit patches for parts of the code where someone else
> > is working since it creates a mess of conflicts, but would you like me
> > to have a go at a patch for removing rcaps?
> 
> Yes, absolutely; please go ahead and do it. I'm happy to rebuild my
> patches on top of that -- I won't really approach the new situation as
a
> rebase, with conflicts to resolve, but as a series of potential
> individual cherry picks, and reimplementations from zero.
I'll have a go at this, probably not going to be til Monday though.
> When removing code, my main question is always "granularity". I
prefer
> "finest granularity" in general, but that may not be right in
this case
> (or in the v2v projects in general). It depends quite a bit on reviewer
> preference.
Finest granularity is usually good for me too.

I try to keep an eye out for what could be cherry-picked onto the
stable branch, thus splitting patches into bug fixes, refactoring, and
feature additions separately.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On 11/06/21 18:40, Richard W.M. Jones wrote:
> On Sat, Nov 06, 2021 at 04:45:33PM +0100, Laszlo Ersek wrote:
>> On 11/02/21 09:52, Richard W.M. Jones wrote:
>>> I hesitate to submit patches for parts of the code where someone
else
>>> is working since it creates a mess of conflicts, but would you like
me
>>> to have a go at a patch for removing rcaps?
>>
>> Yes, absolutely; please go ahead and do it. I'm happy to rebuild my
>> patches on top of that -- I won't really approach the new situation
as a
>> rebase, with conflicts to resolve, but as a series of potential
>> individual cherry picks, and reimplementations from zero.
> 
> I'll have a go at this, probably not going to be til Monday though.
I'm done with the raw rebase (without handling the OVF, JSON and
OpenStack outputs).

I've noticed that the cirrus device model has become effectively dead
too, meaning both the Cirrus constructor of type
"guestcaps_video_type",
and the Source_Cirrus constructor of type "source_video".

If I remove those constructors, then each type will be left with a
single constructor -- "guestcaps_video_type" will only have
Standard_VGA
(not parametric), and "source_video" will have only
"Source_other_video
of string" (basically: a string).

This suggests that "guestcaps_video_type" should be eliminated
altogether (its occurrences could be replaced by constants), and that
"source_video" should be replaced by plain "string".

(I'll go further: "source_video" looks unused beyond
"--print-source",
so it could be removed fully as well!)

Should I attempt doing this at the end of the series?

I'm asking now because these simplifications look technically possible
even before I start investigating the "OVF video device" topic. I
expect
the latter to turn into an infinite mess, so if I can (or should) tack
the cirrus cleanup patches to the end of my series, I figure I'd like to
do that first.

Thanks!
Laszlo