11:07 a.m.
On Fri, 2019-09-20 at 15:12 +0100, Daniel P. Berrangé wrote:
[...]
+ This document attempts to outline the libvirt project strategy
for
+ the near future. Think of this is a high level vision or todo list
s/is a high/as a high/
+ setting the direction for the project & its developers to
take
Missing period at the end of the sentence.
Also:
strategy.html.in:10: parser error : xmlParseEntityRef: no name
setting the direction for the project & its developers to take
^
I would just use "and" anyway.
[...]
+ <dt>Perl</dt>
+ <dd>Various supporting build/test scripts are written in Python. It is
s/Python/Perl/
[...]
+ <dt>XSLT</dt>
+ <dd>The website documentation is subsituted into templates using XSLT
+ scripts.
s/subsituted/substituted/
But I would probably reword it along the lines of
The website uses XSLT for its templating system.
[...]
+ <dt>automake</dt>
+ <dd>The make recipes make use of automake's make language extensions
+ which are then turned into regular make rules</dd>
Let's try to avoid using "make" every other word. How about something
like
automake extends the capabilities of GNU make by introducing a
declarative syntax that can be used to describe recipes
[...]
+ <dt>POD</dt>
+ <dd>The command line manual pages are typically written in Perl's POD
+ format, and converted to troff</dt>
strategy.html.in:53: parser error : Opening and ending tag mismatch: dd line 52 and dt
format, and converted to troff</dt>
^
[...]
+ The C language has served libvirt well over the years, but its
age shows
+ giving rise to limitations which negatively impact the project in terms
+ of code quality, reliability, and efficiency of development. Most notably
+ its lack of memory safety means that many code bugs become trivially
+ exploitable security flaws or denial of service. The lack of a high
+ level portable runtime, resulting in alot of effort being spent to
s/alot/a lot/
+ ensure cross platform portability. The modern languages Rust
and Go
+ provide viable options for low level systems programming, in a way that
+ was not practical with other common languages such as Python and Java.
+ There is thus a desire to make use of either Rust or Go, or more likely
+ a combination of both, to incrementally replace existing use of C, and
+ also for greenfield development.
I would drop the "or more likely a combination of both" because I'm
hoping that we'll be able to standardize on a single one: using a
mix of both would once again increase the burden placed upon
contributors, which is the very problem we're trying to address.
Perhaps we're going to end up with both after all, but I would not
include language encouraging this.
[...]
+ <dt>C</dt>
+ <dd>The core libvirt library, daemons, and helper tools are all written
+ in the C language.</dd>
This reads to me as to say that all of the above are implemented
using C only, which contradicts the points below. I would also single
out the public API as the one part that will need to remain in C. So
perhaps something like
The core library, daemons and helper tools will continue to be
written mostly in C for the foreseeable future. Even as other
programming languages are introduced, libvirt will continue to
offer a <a href="support.html">stable C API/ABI</a>.
+ <dt>Rust</dt>
+ <dd>Parts of the core libvirt library / daemon are to be able to leverage
+ Rust to replace C. (TBD vs Go)</dd>
+ <dt>Go</dt>
+ <dd>Parts of the core libvirt library / daemon are to be able to leverage
+ Rust to replace C. (TBD vs Rust). Helper tools are able to be written
+ in Go.</dd>
There's no reason Rust could be used for the library and daemons but
not be suitable for helper tools. I'd just have a single section for
the two languages, something like
Rust and Go
These languages should be usable as an alternative to C in all the
areas listed above: new code should favor them over C, and existing
C code may be ported after carefully considering the pros and cons
of doing so.
[...]
+ <dt>RST</dt>
I would s/RST/reStructuredText/ at least in this first occurrence.
[...]
+ Some notable points from the above. Whether the core library /
daemons
+ will use Rust or Go internally is still to be decided based on more
+ detailed evaluation of their pros and cons, to identify the best fit,
+ as the need to link & embed this functionality in other processes has
strategy.html.in:114: parser error : xmlParseEntityRef: no name
as the need to link & embed this functionality in other processes has
^
+ complex interactions both at a technical and non-technical
level. For
+ standalone helper tools, Go is a good fit for rapid development as
+ there are no concerns around interactions with other in-process code
+ from 3rd parties.
As mentioned above, if Rust is good enough to be used for the core
library and the daemons it is also good enough for user-facing tools
and helpers.
[...]
+ Using the RST format for documentation allows for the use of
XSLT to be
+ eliminated from the build process. RST and the Sphinx toolkit are widely
+ used, as seen by the huge repository of content on
+ https://readthedocs.org/. The ability embed raw HTML in the RST docs will
s/ability/ability to/
+ greatly facilitate its adoption, avoiding the need for a big
bang
+ conversion of existing content. Given the desire to eliminate Perl
+ usage, replacing the use of POD documentation for manual pages is an
+ obvious followup task. RST is the obvious choice to given alignment
s/given/give/
Even then, the sentence doesn't quite flow. Perhaps use "achieve"
instead?
+ with the website, allowing the man pages to be easily
published online
+ with other docs. It is further anticipated that the current API docs
+ generator which uses XSLT to convert the XML API description would be
+ converted to something which generates RST using Python instead of XSL.
s/XSL/XSLT/
Overall the document is good and the overall strategy is IMHO solid.
--
Andrea Bolognani / Red Hat / Virtualization