linux-kernel - Re: RFC: reviewer's statement of oversight

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18194.46555.18395.586488@notabene.brown>
Date:	Mon, 15 Oct 2007 10:35:39 +1000
From:	Neil Brown <neilb@...e.de>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org
Subject: Re: RFC: reviewer's statement of oversight

On Tuesday October 9, sam@...nborg.org wrote:
> Hi Neil.
> > 
> >    From:        The Author, Primary Author, or Authors of the patch.
> >                 Authors should also provide a Signed-off-by: tag.
> > 
> >                 Purpose: to give credit to authors
> The SCM should include this info and we should not duplicate this
> in the changelog's.
> I know some tools require this format but that's something else.

If the SCM stores some tags in special places, that is fine with me.
The remove the need for the tag and an understanding of why it exists.
Can 'git' store a list of Authors?  Do we want to allow a list?

> 
> > > +
> > > +Signed-off-by:  A person adding a Signed-off-by tag is attesting that the
> > > +		patch is, to the best of his or her knowledge, legally able
> > > +		to be merged into the mainline and distributed under the
> > > +		terms of the GNU General Public License, version 2.  See
> > > +		the Developer's Certificate of Origin, found in
> > > +		Documentation/SubmittingPatches, for the precise meaning of
> > > +		Signed-off-by.
> > 
> >                 Purpose: to allow subsequent review of the originality of 
> >                 the contribution should copyright questions arise.
> 
> We often use s-o-b to docuemnt the path a patch took from origin (the
> top-most s-o-b) to tree apply (lowest s-o-b).
> This is IIUC part of the intended behaviour of s-o-b but it is not
> clear from the above text.

My understanding of Andrew Morton's position on s-o-b is that it is an
unordered set.  I know this because when I have sent him patches with
a proper From: line, he has complained and begrudingly took the first
s-o-b, but said he didn't like to.
So there seems to be disagreement on this (I think it looks like a
path to - but apparently not to everyone).

> 
> 
> > > +
> > > +Acked-by:	The person named (who should be an active developer in the
> > > +		area addressed by the patch) is aware of the patch and has
> > > +		no objection to its inclusion.  An Acked-by tag does not
> > > +		imply any involvement in the development of the patch or
> > > +		that a detailed review was done.
> > 
> >                 Purpose:  to inform upstream aggregators that
> > 		consensus was achieved for the change.  This is
> > 		particularly relevant for changes that affect multiple
> > 		Maintenance Domains.
> > 
> consensus seems too strong a wording here. consensus imply more than one
> that agree on the patch where I often see people give their "Acked-by:" by
> simple changelog reading.

I'm failing to follow your logic.
You seem to be contrasting:
  "consensus imply more than one that agree"
     which I agree with:  "From" plus all "Acked-By" will be more than
     one in all cases that "Acked-By" is used
with
  "people give their "Acked-by:" by simple changlog reading"
     which I also agree with but this just highlights that "Acked-by"
     is different from "Reviewed-by" 

Confused.

Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/