From: Sam Ravnborg <sam@ravnborg.org>
To: Neil Brown <neilb@suse.de>
Cc: Jonathan Corbet <corbet@lwn.net>, linux-kernel@vger.kernel.org
Subject: Re: RFC: reviewer's statement of oversight
Date: Mon, 15 Oct 2007 16:32:39 +0200 [thread overview]
Message-ID: <20071015143239.GA21361@uranus.ravnborg.org> (raw)
In-Reply-To: <18194.46555.18395.586488@notabene.brown>
On Mon, Oct 15, 2007 at 10:35:39AM +1000, Neil Brown wrote:
> On Tuesday October 9, sam@ravnborg.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?
git stores to my best knowledge only a single author.
Infrequently we need a list but then people have solved it putting
relevant people in s-o-b and by give credit in changelog.
This is IMHO good enugh.
>
> >
> > > > +
> > > > +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).
With the current definition you need to supply BOTH a from: and a s-o-b.
I usually request a s-o-b when it is missing no matter what other content
is present in the changelog.
>
> >
> >
> > > > +
> > > > +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
I did not realise that "concensus" in this context refered to both the
one that give the "Acked-by" and the author.
Viewing it this way I agree with the intent and the text.
Sam
next prev parent reply other threads:[~2007-10-15 14:31 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-08 17:24 RFC: reviewer's statement of oversight Jonathan Corbet
2007-10-08 17:31 ` Pekka Enberg
2007-10-08 17:37 ` Sam Ravnborg
2007-10-08 17:45 ` Jan Engelhardt
2007-10-08 18:01 ` Jeremy Fitzhardinge
2007-10-08 18:06 ` Randy Dunlap
2007-10-08 18:16 ` Jeremy Fitzhardinge
2007-10-08 18:34 ` Stefan Richter
2007-10-08 18:52 ` J. Bruce Fields
2007-10-08 19:04 ` Stefan Richter
2007-10-08 19:26 ` Scott Preece
2007-10-08 20:16 ` Rafael J. Wysocki
2007-10-09 2:07 ` Steven Rostedt
2007-10-09 6:11 ` Stefan Richter
2007-10-09 6:27 ` Sam Ravnborg
2007-10-09 6:39 ` Stefan Richter
2007-10-09 6:47 ` Stefan Richter
2007-10-08 18:26 ` Stefan Richter
2007-10-08 18:40 ` Roland Dreier
2007-10-08 19:35 ` Scott Preece
2007-10-08 20:33 ` H. Peter Anvin
2007-10-08 21:38 ` Theodore Tso
2007-10-08 22:18 ` Rafael J. Wysocki
2007-10-08 23:20 ` Oleg Verych
2007-10-08 22:43 ` Jonathan Corbet
2007-10-08 23:06 ` Randy Dunlap
2007-10-09 3:34 ` Stephen Hemminger
2007-10-08 23:30 ` J. Bruce Fields
2007-10-09 10:28 ` Alan Cox
2007-10-08 23:42 ` Stefan Richter
2007-10-09 0:05 ` Neil Brown
2007-10-09 16:49 ` Jonathan Corbet
2007-10-09 17:25 ` Roland Dreier
2007-10-10 0:06 ` David Chinner
2007-10-15 0:27 ` Neil Brown
2007-10-09 17:44 ` Sam Ravnborg
2007-10-15 0:35 ` Neil Brown
2007-10-15 14:32 ` Sam Ravnborg [this message]
2007-10-10 13:40 ` Scott Preece
2007-10-08 18:40 ` Mark Gross
2007-10-08 18:53 ` Stefan Richter
2007-10-08 19:05 ` Al Viro
2007-10-08 19:08 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071015143239.GA21361@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.