Libguestfs - Jan 2020 - Re: [PATCH libnbd] python: Add AIO buffer is_zero method.

On Thu, Jan 30, 2020 at 08:16:30AM -0600, Eric Blake
wrote:
> On 1/30/20 8:05 AM, Richard W.M. Jones wrote:
> >Fast testing whether the AIO buffer (or regions within it) contain all
> >zeroes, which allows Python code to quickly do sparsification when
> >copying.
> >
> >This includes the iszero.h header from nbdkit which is distributed
> >under a compatible license.
> >---
> >  common/include/Makefile.am  |  5 +--
> >  common/include/iszero.h     | 63
+++++++++++++++++++++++++++++++++++++
> >  generator/generator         | 17 ++++++++--
> >  python/Makefile.am          |  3 +-
> >  python/handle.c             | 47 +++++++++++++++++++++++++++
> >  python/t/580-aio-is-zero.py | 53 +++++++++++++++++++++++++++++++
> >  6 files changed, 183 insertions(+), 5 deletions(-)
> 
> ACK.
> 
> 
> >+++ b/common/include/Makefile.am
> >@@ -1,5 +1,5 @@
> >  # nbd client library in userspace
> >-# Copyright (C) 2013-2019 Red Hat Inc.
> >+# Copyright (C) 2013-2020 Red Hat Inc.
> 
> Unrelated question: we are just now making our first libnbd commits
> of 2020.  Should we have the 'nbdsh --version' output a copyright
> date?
I guess the first line of output must remain as it is now, but we
could add further lines if we wanted to.  Seems like GNU tools follow
some kind of standard where they print <name> <version> on the first
line, then copyright and license information on subsequent lines.
> And if so, should we automate the process to automatically update it
> to the current year, rather than remembering to touch files manually
> when making the first commit in a year?
Need to be careful about not breaking reproducible builds.  This was a
problem in the past with libguestfs where it would insert a copyright
year into certain output files based on the time of compilation.

https://github.com/libguestfs/libguestfs/commit/4d39faaa30eace5f52e92e344d3a62dcce52d71c
> Should we
> manually update the copyright date in ALL files in a single pass,
> rather than one-off edits as we make per-file changes (if so, the
> gnulib project has a nice script for automating a tree-wide
> copyright range update).
We could run the following command over all repository:

https://github.com/libguestfs/libguestfs/commit/05d4fcb64d98d4ff1d57560c566ca8e66b695277

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

On Thu, Jan 30, 2020 at 02:29:21PM +0000, Richard W.M. Jones
wrote:
>On Thu, Jan 30, 2020 at 08:16:30AM -0600, Eric Blake wrote:
>> On 1/30/20 8:05 AM, Richard W.M. Jones wrote:
>> >Fast testing whether the AIO buffer (or regions within it) contain
all
>> >zeroes, which allows Python code to quickly do sparsification when
>> >copying.
>> >
>> >This includes the iszero.h header from nbdkit which is distributed
>> >under a compatible license.
>> >---
>> >  common/include/Makefile.am  |  5 +--
>> >  common/include/iszero.h     | 63
+++++++++++++++++++++++++++++++++++++
>> >  generator/generator         | 17 ++++++++--
>> >  python/Makefile.am          |  3 +-
>> >  python/handle.c             | 47 +++++++++++++++++++++++++++
>> >  python/t/580-aio-is-zero.py | 53 +++++++++++++++++++++++++++++++
>> >  6 files changed, 183 insertions(+), 5 deletions(-)
>>
>> ACK.
>>
>>
>> >+++ b/common/include/Makefile.am
>> >@@ -1,5 +1,5 @@
>> >  # nbd client library in userspace
>> >-# Copyright (C) 2013-2019 Red Hat Inc.
>> >+# Copyright (C) 2013-2020 Red Hat Inc.
>>
>> Unrelated question: we are just now making our first libnbd commits
>> of 2020.  Should we have the 'nbdsh --version' output a
copyright
>> date?
>
>I guess the first line of output must remain as it is now, but we
>could add further lines if we wanted to.  Seems like GNU tools follow
>some kind of standard where they print <name> <version> on the
first
>line, then copyright and license information on subsequent lines.
>
>> And if so, should we automate the process to automatically update it
>> to the current year, rather than remembering to touch files manually
>> when making the first commit in a year?
>
>Need to be careful about not breaking reproducible builds.  This was a
>problem in the past with libguestfs where it would insert a copyright
>year into certain output files based on the time of compilation.
>
>https://github.com/libguestfs/libguestfs/commit/4d39faaa30eace5f52e92e344d3a62dcce52d71c
>
>> Should we
>> manually update the copyright date in ALL files in a single pass,
>> rather than one-off edits as we make per-file changes (if so, the
>> gnulib project has a nice script for automating a tree-wide
>> copyright range update).
>
>We could run the following command over all repository:
>
>https://github.com/libguestfs/libguestfs/commit/05d4fcb64d98d4ff1d57560c566ca8e66b695277
>
I know this probably got answered somewhere, but I've never gotten any when
asking myself.  So let me use this opportunity.

Because I really despise useless processes and duplicated information I always
hated the way all the "mandatory" file headers.  As far as I
understand it's
related to the fact that the file itself used to be the only source of
information about where the code came from.  Nowadays we have more information
in git.

The reason all this is happening is to be able to prove that there is traceable
source of the code, right?  I, personally, do not really like when you get
couple of lines of repeated information on every start of the tool (`bc` should
only ever be ran with `-q` for any sane person).  In my opinion that is never
going to help any user.

All of this comes down to whether you prove the above if push comes to shove.
GPL talks about the headers and where are all the places you *should* put the
copyright notices and license information.  But I think it comes to the
"should"
and since it is written "to make lawyers more confident" about 30
years ago it
might've kept some of the reservations from that era.

Finally the question: How much of a problem would it be if we just limited the
information in file headers to minimum and pointed people to git history and
central license?

Sorry for making you read all this, but I feel like you're very
knowledgeable
and I struggle with this on a regular basis, so some consensus would help me.

Have a nice day,
Martin
>Rich.
>
>-- 
>Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
>Read my programming and virtualization blog: http://rwmj.wordpress.com
>virt-df lists disk usage of guests without needing to install any
>software inside the virtual machine.  Supports Linux and Windows.
>http://people.redhat.com/~rjones/virt-df/

On Thu, Jan 30, 2020 at 04:16:09PM +0100, Martin Kletzander
wrote:
> I know this probably got answered somewhere, but I've never gotten
> any when asking myself.  So let me use this opportunity.
>
> Because I really despise useless processes and duplicated
> information I always hated the way all the "mandatory" file
headers.
> As far as I understand it's related to the fact that the file itself
> used to be the only source of information about where the code came
> from.  Nowadays we have more information in git.
>
> The reason all this is happening is to be able to prove that there
> is traceable source of the code, right?  I, personally, do not
> really like when you get couple of lines of repeated information on
> every start of the tool (`bc` should only ever be ran with `-q` for
> any sane person).  In my opinion that is never going to help any
> user.
>
> All of this comes down to whether you prove the above if push comes
> to shove.  GPL talks about the headers and where are all the places
> you *should* put the copyright notices and license information.  But
> I think it comes to the "should" and since it is written "to
make
> lawyers more confident" about 30 years ago it might've kept some
of
> the reservations from that era.
>
> Finally the question: How much of a problem would it be if we just
> limited the information in file headers to minimum and pointed
> people to git history and central license?
>
> Sorry for making you read all this, but I feel like you're very
> knowledgeable and I struggle with this on a regular basis, so some
> consensus would help me.
Questions of a legal nature should be addressed to and answered by
lawyers, but it's my current understanding that we need the
boilerplate in files to make a cast iron assertion of copyright,
licensing and warranty conditions.  Until a lawyer (from RH Legal in
this case) tells me otherwise, I'm afraid we need to keep the
boilerplate.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW