qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 00/10] Enable repository wide style checking


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH RFC 00/10] Enable repository wide style checking
Date: Fri, 14 Aug 2015 10:57:05 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Aug 13, 2015 at 09:39:48PM +0100, Peter Maydell wrote:
> On 13 August 2015 at 19:27, Eric Blake <address@hidden> wrote:
> > It's worth asking the gnulib folks for an opinion on whether relaxing
> > the license on maint.mk and GNUmakefile to explicitly go back to GPLv2+,
> > and/or explicitly add some explicit exception clause like gcc that makes
> > it clear that using these files to build does not taint the built
> > product.  Personally, I see no problem with using GPLv3'd tools (after
> > all, qemu requires GPLv3 GNU make, and gcc is also GPLv3 although clang
> > can step around that one), but I also see your reluctance of even having
> > a file in the qemu.git repo that has a GPLv3 clause.
> 
> Right; we don't ship make or gcc in our code repo, and using
> external-to-the-repository tools which happen to be GPLv3 is
> obviously fine. Similarly, if you used the maint.mk script externally
> as a tool which allowed you to find bugs which you submitted
> patches to fix that wouldn't be a problem. I just don't want
> a GPLv3-licensed file in the git repo and an integrated part
> of our build-and-test system...

Ok, I certainly understand why we can't have GPLv3 code built
into QEMU, but I thought build-system tests would be ok because
it does not affect the built binaries in any way.

> I would certainly appreciate a maint.mk with a GPLv2-or-later
> license. Our other options are (a) use the last v2+ version
> (which is what we do with our binutils disassemblers)
> (b) do the style checks we care about some other way or
> (c) don't bother doing the style checks at all.

Option (b) could involve re-factoring the existing check_patch.pl
script to give us the 2 main benefits from the gnulib check code

 - Ability to turn on/off individual rules on a per-file basis
 - Ability to run against the entire codebase not just patches

IIUC, the check_patch.pl script was imported from Linux, so I'm
not sure if there is a general desire to minimize the divergance
from the original file, or whether refactoring would be welcome ?

I can certainly explore the viability of such an approach if people
are conceptually open to some significant changes to check_patch.pl

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]