8:49 a.m.
On Tue, Apr 19, 2022 at 15:23:07 +0200, Victor Toso wrote:
Hi,
On Tue, Apr 19, 2022 at 02:31:01PM +0200, Peter Krempa wrote:
> On Thu, Apr 14, 2022 at 22:47:11 +0200, Victor Toso wrote:
> > Hi,
>
> Couple of comments which I summarize on the top level rather than doing
> specifics since they might need a reorg of the series:
>
> >
> > The goal of this patch series is to provide 'since' version to all
> > exported types.
> >
> > This is the non lazy version of the v1. In this series, we do
> > change the docstrings of all exported types, to add the version
> > metadata, in order to have scripts/apibuild.py to fetch it and add
> > it to the appropriated XML API. This patch series also enforces
> > that every new exported types requires a docstring with version
> > with the proper format.
> >
> > v1: https://listman.redhat.com/archives/libvir-list/2022-April/229881.html
> >
> > I've created a script that helped me out and it covered a good
> > amound of cases. I hand fixes all the missing docstrings and
> > corner cases that my script missed.
> >
> > As mentioned in v1, I've used:
> >
> > git grep -rq $symbol $tag $includedir
> >
> > This is used to find if a given $symbol exists in a given $tag or
> > not. $tag starts with v1.0.0 and I have ignored any $tag that does
> > not start with 'v' or has '-rc' in the name.
> >
> > To help review this not so small changeset, the changes were split
> > in the following order:
> >
> > * docs: generated: 98% work from the script. I've split it
> > further, by module + group type.
> >
> > * docs: manual: -> 30% manual labor, 70% vim's macro. It was also
> > split where it seems reasonable.
> >
> > * docs: (...) -> Some fixes needed in the docs.
> >
> > * scripts: -> Improvements to apibuild script.
> >
> > * syms: -> Some fixes found with the found mismatch between
> > docstring and sym files.
> >
> > Other than that, I only caught two false positives, that is, a $symbol
> > was present in a $tag but it was exported only at a latter $tag.
> >
> > Branch : https://gitlab.com/victortoso/libvirt/-/commits/add-since-version
> > Green CI: https://gitlab.com/victortoso/libvirt/-/pipelines/517262280
> >
> > Cheers,
> > Victor
> >
> > Victor Toso (34):
> > docs: Fix generated documentation of virConnectListAllNodeDeviceFlags
> > docs: variable: Move docstring from source to header file
> > docs: generated: enums: libvirt: append 'Since version' metadata
>
> The tree fails to build after this commit. Per our guidelines the tree
> must be buildable after every single commit:
>
> https://www.libvirt.org/hacking.html#preparing-patches
>
> This is to ensure bisectability. You'll need to reorganize the
> fixes you've done after applying the changes automatically to
> happen before or at the same time to ensure compliance.
Thank you. I thought I had it covered with a `git rebase -i
--exec `. I'll double check and fix.
>
> > docs: generated: enums: qemu: append 'Since version' metadata
> > docs: generated: enums: admin: append 'Since version' metadata
> > docs: generated: macros: libvirt: append 'Since version' metadata
> > docs: generated: macros: admin: append 'Since version' metadata
> > docs: generated: typedefs: libvirt: append 'Since version' metadata
> > docs: generated: typedefs: qemu: append 'Since version' metadata
> > docs: generated: typedefs: admin: append 'Since version' metadata
> > docs: generated: functions: libvirt: append 'Since version' metadata
> > docs: generated: functions: qemu: append 'Since version' metadata
> > docs: generated: functions: lxc: append 'Since version' metadata
> > docs: generated: functions: admin: append 'Since version' metadata
> > docs: manual: typedef: add docstring and Since metadata
> > docs: manual: functions: add Since metadata
> > docs: manual: enums: add docstring and Since metadata
> > docs: manual: macros: add docstring and Since metadata
> > docs: manual: libvirt-common: add docstring and Since metadata
> > docs: Fix generated documentation of virStorageVolInfoFlags
> > docs: Fix and append Since to virConnectListAllStoragePoolsFlags
> > docs: Fix and append Since to virDomainDeviceModifyFlags
> > docs: Fix and append Since to virDomainMemoryModFlags
> > docs: Fix and append Since to virDomainVcpuFlags
>
> None of these actually change anything in the 'docs' directory. I'd
> suggest to pick an unambiguous prefix such as "symbols" or something
> similar.
Makes sense. Would "docstrings" be preferred over "symbols" ?
Sure
> > scripts: apibuild: parse 'Since' version for enums
> > scripts: apibuild: fix parsing block comments from typedef enum
> > scripts: apibuild: parse 'Since' for typedefs
> > scripts: apibuild: parse 'Since' for macros
>
> After the fix mentioned below [1] the build of the tree breaks after
> this commit:
>
> FAILED: docs/libvirt-api.xml docs/libvirt-lxc-api.xml docs/libvirt-qemu-api.xml
docs/libvirt-admin-api.xml
> /home/pipo/libvirt/scripts/meson-python.sh /bin/python3
/home/pipo/libvirt/scripts/apibuild.py /home/pipo/libvirt/docs
/home/pipo/build/libvirt/gcc/docs
> Function virDomainSetBlockThreshold has symversion 3.1.0 but docstring says 3.2.0
> Function virAdmClientClose has symversion 2.0.0 but docstring says 1.3.5
> Function virAdmClientFree has symversion 2.0.0 but docstring says 1.3.5
> Function virAdmClientGetID has symversion 2.0.0 but docstring says 1.3.5
Considering your comment bellow, I'll remove the docstring's
version comparison with what is provided by .syms file.
Actually the check itself might be a good idea, because it gives you one
more possibility to catch the mistake of e.g. exposing a symbol in the
wrong version.
IMO since we are actually not striving on adding any more miss-exported
symbols I'd simply exempt the few wrong examples from the check.
My only question is, which one should be documented in the XML
API?
I didn't look closely at the admin API changes, but in case of
'virDomainSetBlockThreshold' the API was really added in 3.2.0 even if
the symbol is exported under the 3.1.0 version, so 3.2.0 is correct in
this case.
Arguably at this point it doesn't matter too much given how old those
releases are.