On Thu, Jan 25, 2018 at 11:13:40AM +0100, Peter Krempa wrote: > On Mon, Jan 22, 2018 at 13:57:07 +0000, Daniel Berrange wrote: > > On Mon, Jan 22, 2018 at 02:20:52PM +0100, Peter Krempa wrote: > > > On Mon, Jan 22, 2018 at 13:06:28 +0000, Daniel Berrange wrote: > > > > On Mon, Jan 22, 2018 at 01:20:12PM +0100, Peter Krempa wrote: > > > > > On Mon, Jan 22, 2018 at 12:05:19 +0000, Daniel Berrange wrote: > > > > > > This extends the update hook so that it enforces a requirement to have a > > > > > > Signed-off-by line in every commit message. This can be optionally > > > > > > turned off in individual repos by setting the "hooks.allowmissingsob" > > > > > > git config variable. > > > > > > > > > > > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > > > > > > --- > > > > > > update | 16 +++++++++++++++- > > > > > > 1 file changed, 15 insertions(+), 1 deletion(-) > > [..] > > > > The sign-off by itself (whithout cryptographic signature) is just > > > pointless. Validity with a cryptographic signature from drive-by > > > contributors can still be unproven, but at least you don't get > > > impersonation. > > > > I think these are two different axis. The sob isn't trying to address the > > question of impersonation. It obviously has as a starting point that you > > accept the identity of the submitter to some degree. I accept that if you > > have cryptographically signed patches, that would give a stronger > > validation of identity, but there's never any absolutes. So not having > > a crypto signature doesn't make the sob invalid. > > In that case basically nothing changes, since if we are going to use > this to be safe from licensing disputes, the reviewer/commiter still > needs to make sure that the code complies with our licensing. Asserting > the signoff changes nothing in that regard > > > > > > If everything is signed off, nothing really is. > > > > I don't really see that. > > > > > NACK still stands. > > > > You are nacking something that you've accepted above will have no negative > > impact on your work, but has potentially significant upside to the project. > > That is very disappointing. > > I think that by doing this we'll put too much false hope into the > "potentially significant upside". I just hope it will not bite us. > > Anyone can assert, or sign-off anything [1]. > > Given the overwhelmingly positive approach to this retract my NACK, the > only thing that will change in general is that my commits will grow one > line. Thanks, I appreciate that. FYI, i'm not going to push the hook right now, since I'm on holiday for 3 days and its always bad to do changes to dev workflow before going away :-) I'll do it next week when i return.... Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
