9:16 a.m.
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/4d39faaa30eace5f52e92e344...
> 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/05d4fcb64d98d4ff1d57560c5...
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/