From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Zhao Liu <zhao1.liu@intel.com>
Cc: qemu-devel@nongnu.org,
"Richard Henderson" <richard.henderson@linaro.org>,
"Alexander Graf" <agraf@csgraf.de>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Phil Mathieu-Daudé" <philmd@linaro.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Thomas Huth" <thuth@redhat.com>, "Kevin Wolf" <kwolf@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [PATCH 1/2] docs: introduce dedicated page about code provenance / sign-off
Date: Mon, 29 Jan 2024 09:31:49 +0000 [thread overview]
Message-ID: <ZbdwhR6h6T97vR8J@redhat.com> (raw)
In-Reply-To: <ZbUU6CTgxgCLG0a9@intel.com>
On Sat, Jan 27, 2024 at 10:36:24PM +0800, Zhao Liu wrote:
> Hi Daniel,
>
> On Thu, Nov 23, 2023 at 11:40:25AM +0000, Daniel P. Berrangé wrote:
> > +Multiple authorship
> > +~~~~~~~~~~~~~~~~~~~
> > +
> > +It is not uncommon for a patch to have contributions from multiple
> > +authors. In such a scenario, a git commit will usually be expected
> > +to have a ``Signed-off-by`` line for each contributor involved in
> > +creatin of the patch. Some edge cases:
> > +
> > + * The non-primary author's contributions were so trivial that
> > + they can be considered not subject to copyright. In this case
> > + the secondary authors need not include a ``Signed-off-by``.
> > +
> > + This case most commonly applies where QEMU reviewers give short
> > + snippets of code as suggested fixes to a patch. The reviewers
> > + don't need to have their own ``Signed-off-by`` added unless
> > + their code suggestion was unusually large.
> > +
> > + * Both contributors work for the same employer and the employer
> > + requires copyright assignment.
> > +
> > + It can be said that in this case a ``Signed-off-by`` is indicating
> > + that the person has permission to contributeo from their employer
> > + who is the copyright holder.
>
> For this case, maybe it needs the "Co-developed-by"?
If you're going to go to the trouble of adding multiple tags
to the commit for each author who participated, then IMHO they
should all be Signed-off-by. IOW, either just have S-o-B from
the main author within a company, or have S-o-B for every
author. Co-developed-by doesn't have value IMHO.
> > It is none the less still preferrable
> > + to include a ``Signed-off-by`` for each contributor, as in some
> > + countries employees are not able to assign copyright to their
> > + employer, and it also covers any time invested outside working
> > + hours.
> > +
> > +Other commit tags
> > +~~~~~~~~~~~~~~~~~
> > +
> > +While the ``Signed-off-by`` tag is mandatory, there are a number of
> > +other tags that are commonly used during QEMU development
> > +
> > + * **``Reviewed-by``**: when a QEMU community member reviews a patch
> > + on the mailing list, if they consider the patch acceptable, they
> > + should send an email reply containing a ``Reviewed-by`` tag.
>
> Maybe just a question, the people should drop the Reviewed/ACKed/Tested
> tags that have been obtained if he make the any code changes (including
> function/variable renaming) as well as commit message changes during
> the patch refresh process, am I understand correctly? ;-)
It is a judgement call as to whether a Reviewed-by/etc should be
kept or dropped. It depends on the scale of the changes that
were made to the commit since the Reviewed-by/etc was first given.
> > + NB: a subsystem maintainer sending a pull request would replace
> > + their own ``Reviewed-by`` with another ``Signed-off-by``
> > +
> > + * **``Acked-by``**: when a QEMU subsystem maintainer approves a patch
> > + that touches their subsystem, but intends to allow a different
> > + maintainer to queue it and send a pull request, they would send
> > + a mail containing a ``Acked-by`` tag.
> > +
> > + * **``Tested-by``**: when a QEMU community member has functionally
> > + tested the behaviour of the patch in some manner, they should
> > + send an email reply conmtaning a ``Tested-by`` tag.
>
> Is there any requirement for the order of tags?
>
> My previous understanding was that if the Reviewed-by/Tested-by tags
> were obtained by the author within his company, then those tags should
> be placed before the signed-off-by of the author. If the Reviewed-by/
> Tested-by were acquired in the community, then they should be placed
> after the author's signed-off-by, right?
Common practice is for Signed-off-by tags to be kept in time order
from earliest author to latest author / maintainer. Common case is
2 S-o-B, the first from the patch author, and the last from the
sub-system maintainer who sends the pull request.
For other tags I don't see any broadly acceptable pattern. Some people
add Reviewed-by before the S-o-B, others add Reviewed-by after the
S-o-B. Either is fine IMHO.
> > +Re-starting abandoned work
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +For a variety of reasons there are some patches that get submitted to
> > +QEMU but never merged. An unrelated contributor may decide (months or
> > +years later) to continue working from the abandoned patch and re-submit
> > +it with extra changes.
> > +
> > +If the abandoned patch already had a ``Signed-off-by`` from the original
> > +author this **must** be preserved.
>
> I find some people added Originally-by, e.g., 8e86851bd6b9.
>
> I guess if the code has been changed very significantly, or if the
> original implementation has just been referenced and significantly
> refactored, then Originally-by should be preferred instead of
> Signed-off-by from the original author, right?
If patch submitted still contains any code that can be considered
copyrightable (ie anything non-trivial) from the original author,
then I would expect the original authors Signed-off-by to be retained.
I think the cases where it is ok to use Originally-by, without a
Signed-off-by, would be exceedingly.
With 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 :|
next prev parent reply other threads:[~2024-01-29 9:32 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 11:40 [PATCH 0/2] docs: define policy forbidding use of "AI" / LLM code generators Daniel P. Berrangé
2023-11-23 11:40 ` [PATCH 1/2] docs: introduce dedicated page about code provenance / sign-off Daniel P. Berrangé
2023-11-23 11:58 ` Philippe Mathieu-Daudé
2023-11-23 17:08 ` Daniel P. Berrangé
2023-11-23 23:56 ` Michael S. Tsirkin
2023-11-23 13:01 ` Peter Maydell
2023-11-23 17:12 ` Daniel P. Berrangé
2023-11-23 13:16 ` Kevin Wolf
2023-11-23 17:12 ` Daniel P. Berrangé
2023-11-23 14:25 ` Michael S. Tsirkin
2023-11-23 17:16 ` Daniel P. Berrangé
2023-11-23 17:33 ` Michael S. Tsirkin
2023-11-24 11:11 ` Philippe Mathieu-Daudé
2023-11-24 11:27 ` Michael S. Tsirkin
2023-11-24 9:49 ` Kevin Wolf
2023-11-23 15:13 ` Stefan Hajnoczi
2024-01-27 14:36 ` Zhao Liu
2024-01-29 9:31 ` Daniel P. Berrangé [this message]
2024-01-29 9:35 ` Samuel Tardieu
2024-01-29 10:41 ` Peter Maydell
2024-01-29 11:00 ` Daniel P. Berrangé
2023-11-23 11:40 ` [PATCH 2/2] docs: define policy forbidding use of "AI" / LLM code generators Daniel P. Berrangé
2023-11-23 12:57 ` Alex Bennée
2023-11-23 17:37 ` Michal Suchánek
2023-11-23 23:27 ` Michael S. Tsirkin
2023-11-23 17:46 ` Daniel P. Berrangé
2023-11-23 23:53 ` Michael S. Tsirkin
2023-11-24 10:17 ` Kevin Wolf
2023-11-24 10:33 ` Alex Bennée
2023-11-24 10:42 ` Michael S. Tsirkin
2023-11-24 10:43 ` Peter Maydell
2023-11-24 11:02 ` Michael S. Tsirkin
2023-11-24 11:37 ` Daniel P. Berrangé
2023-11-24 11:39 ` Michael S. Tsirkin
2023-11-24 11:40 ` Michael S. Tsirkin
2023-11-23 13:20 ` Kevin Wolf
2023-11-23 14:35 ` Michael S. Tsirkin
2023-11-23 14:56 ` Manos Pitsidianakis
2023-11-23 15:13 ` Michael S. Tsirkin
2023-11-23 15:29 ` Philippe Mathieu-Daudé
2023-11-23 17:06 ` Michael S. Tsirkin
2023-11-23 17:29 ` Michal Suchánek
2023-11-23 18:05 ` Michael S. Tsirkin
2023-11-23 15:32 ` Alex Bennée
2023-11-23 18:02 ` Daniel P. Berrangé
2023-11-23 18:10 ` Peter Maydell
2023-11-24 10:25 ` Kevin Wolf
2023-11-24 10:37 ` Michael S. Tsirkin
2023-11-24 10:42 ` Manos Pitsidianakis
2023-11-23 17:58 ` Daniel P. Berrangé
2023-11-23 22:39 ` Michael S. Tsirkin
2023-11-24 9:06 ` Daniel P. Berrangé
2023-11-24 9:27 ` Michael S. Tsirkin
2023-11-24 10:21 ` Alex Bennée
2023-11-24 10:30 ` Michael S. Tsirkin
2023-11-24 11:41 ` Daniel P. Berrangé
2023-11-23 15:22 ` Stefan Hajnoczi
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=ZbdwhR6h6T97vR8J@redhat.com \
--to=berrange@redhat.com \
--cc=agraf@csgraf.de \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
--cc=zhao1.liu@intel.com \
/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.