Issue 90 Further Clarifications

[Dustan B Helm]

[image: Dustan Helm] <https://gitlab.com/dustan.helm>
Dustan Helm <https://gitlab.com/dustan.helm> @dustan.helm
<https://gitlab.com/dustan.helm> · just now
<https://gitlab.com/libvirt/libvirt/-/issues/90#note_451306432>
<https://gitlab.com/libvirt/libvirt/-/issues/90#>

Before we start making changes and solidifying our XML parameter choices,
we have a few clarifying questions about the issue we'd like to get out of
the way.

   1.

   In src/qemu/qemu_capabilities.h, we found the string "/* -drive
   file.driver=vxhs via query-qmp-schema */" after the QEMU_CAPS_VXHS
   declaration. What is the purpose of these strings, and how do we modify
   them to make sense for nfs? Would we simply mirror what is done for VXHS,
   adding nfs as the protocol instead?
   2.

   Where is domain XML parsed and formatted? Is that what is referred to by
   the schema formats in domaincommon.rng?
   3.

   In src/qemu/qemu_block.c, the json object arguments currently present in
   qemuBlockStorageSourceGetVxHSProps(...) are not the same ones listed in the
   example commit. What is the reason for this change, and how should we take
   it into account when implementing a new protocol type?

Additionally, we were hoping we could get some clarification on the proper
way to handle submitting patches with multiple commits. If we receive
feedback for only part of a patch, for example, how would we be meant to
update it? Would we simply amend the particular commit that needed updates,
and if so, how do we amend a commit other than the most recent commit?
Should we send in our patches for review one at a time, or try to get all
of them made and then send them in all at once?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20201119/182442ae/attachment-0001.htm>