Libguestfs - Apr 2022 - [PATCH v2v 0/2] output: Remove -o json mode [in stages]

On 04/11/22 12:11, Richard W.M. Jones wrote:
> I'd like to remove the unused -o json mode.  The implementation is
> over-complicated and the only potential user (KubeVirt) isn't using it
> now and would be better off with a proper -o kubevirt mode, which I'm
> going to implement later.
> 
> My plan would be to add the patches in two stages.  The first patch,
> which only removes the documentation but leaves the feature and test,
> would be applied to stable branch virt-v2v 2.0.  The second patch
> would be go on the development branch 2.1 (which hasn't yet been
> created).  The first stable release without this feature would be 2.2.
If the second patch goes on the 2.1 dev branch, then why wouldn't the
2.1 release include it? (IOW the 2.1 release would not have "-o json"
any more.)

I'm OK with the plan just don't understand how 2.2 is relevant.
> For RHEL I'd probably put both patches in 9.1, even though we're
> planning to ship virt-v2v 2.0.x there.  It means there will be an
> option/feature present in RHEL 9.0 which is removed in 9.1.
I don't think "-o json" is used by anyone at the moment, so in
practice
it shouldn't become a regression.

I'll look at the patches now.

Thanks
Laszlo

On Mon, Apr 11, 2022 at 12:34:30PM +0200, Laszlo Ersek
wrote:
> On 04/11/22 12:11, Richard W.M. Jones wrote:
> > I'd like to remove the unused -o json mode.  The implementation is
> > over-complicated and the only potential user (KubeVirt) isn't
using it
> > now and would be better off with a proper -o kubevirt mode, which
I'm
> > going to implement later.
> > 
> > My plan would be to add the patches in two stages.  The first patch,
> > which only removes the documentation but leaves the feature and test,
> > would be applied to stable branch virt-v2v 2.0.  The second patch
> > would be go on the development branch 2.1 (which hasn't yet been
> > created).  The first stable release without this feature would be 2.2.
> 
> If the second patch goes on the 2.1 dev branch, then why wouldn't the
> 2.1 release include it? (IOW the 2.1 release would not have "-o
json"
> any more.)
Just sticking to the convention so far that 2.x for odd x are
development releases.  We don't care about maintaining backwards
compatibility during the development cycle.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

On 04/11/22 12:34, Laszlo Ersek wrote:
> On 04/11/22 12:11, Richard W.M. Jones wrote:
>> I'd like to remove the unused -o json mode.  The implementation is
>> over-complicated and the only potential user (KubeVirt) isn't using
it
>> now and would be better off with a proper -o kubevirt mode, which
I'm
>> going to implement later.
>>
>> My plan would be to add the patches in two stages.  The first patch,
>> which only removes the documentation but leaves the feature and test,
>> would be applied to stable branch virt-v2v 2.0.  The second patch
>> would be go on the development branch 2.1 (which hasn't yet been
>> created).  The first stable release without this feature would be 2.2.
> 
> If the second patch goes on the 2.1 dev branch, then why wouldn't the
> 2.1 release include it? (IOW the 2.1 release would not have "-o
json"
> any more.)
> 
> I'm OK with the plan just don't understand how 2.2 is relevant.
Ah, having read the first commit message, I think the typo could be the
other way around: you may have meant the 2.2 dev branch (which doesn't
yet exist because there hasn't been a 2.1 release yet). The 2.1 dev
branch is already open OTOH, IIUC.

Thanks
Laszlo
> 
>> For RHEL I'd probably put both patches in 9.1, even though
we're
>> planning to ship virt-v2v 2.0.x there.  It means there will be an
>> option/feature present in RHEL 9.0 which is removed in 9.1.
> 
> I don't think "-o json" is used by anyone at the moment, so
in practice
> it shouldn't become a regression.
> 
> I'll look at the patches now.
> 
> Thanks
> Laszlo
>