qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 2/7] Update CPUs AML with cpu-(ctrl)dev change


From: Daniel P . Berrangé
Subject: Re: [PATCH v3 2/7] Update CPUs AML with cpu-(ctrl)dev change
Date: Tue, 26 Sep 2023 13:30:30 +0100
User-agent: Mutt/2.2.9 (2022-11-12)

On Tue, Sep 26, 2023 at 07:54:04AM -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 26, 2023 at 11:45:19AM +0000, Salil Mehta wrote:
> > 
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Tuesday, September 26, 2023 12:12 PM
> > > To: Salil Mehta <salil.mehta@huawei.com>
> > > Cc: xianglai li <lixianglai@loongson.cn>; qemu-devel@nongnu.org; Bernhard
> > > Beschow <shentey@gmail.com>; Salil Mehta <salil.mehta@opnsrc.net>; 
> > > Xiaojuan
> > > Yang <yangxiaojuan@loongson.cn>; Song Gao <gaosong@loongson.cn>; Igor
> > > Mammedov <imammedo@redhat.com>; Ani Sinha <anisinha@redhat.com>; Paolo
> > > Bonzini <pbonzini@redhat.com>; Richard Henderson
> > > <richard.henderson@linaro.org>; Eduardo Habkost <eduardo@habkost.net>;
> > > Marcel Apfelbaum <marcel.apfelbaum@gmail.com>; Philippe Mathieu-Daudé
> > > <philmd@linaro.org>; wangyanan (Y) <wangyanan55@huawei.com>; Daniel P.
> > > Berrangé <berrange@redhat.com>; Peter Xu <peterx@redhat.com>; David
> > > Hildenbrand <david@redhat.com>; Bibo Mao <maobibo@loongson.cn>
> > > Subject: Re: [PATCH v3 2/7] Update CPUs AML with cpu-(ctrl)dev change
> > > 
> > > On Tue, Sep 26, 2023 at 10:49:08AM +0000, Salil Mehta wrote:
> > > > Hi Xianglai,
> > > > FYI. RFC V2 is out and you can now drop the arch agnostic patches from
> > > > your patch-set. Please check the details in the cover letter which one
> > > > you need to pick and rebase from:
> > > >
> > > > https://lore.kernel.org/qemu-devel/20230926100436.28284-1-
> > > salil.mehta@huawei.com/T/#t
> > > >
> > > > I am planning to float the architecture agnostic patch-set within this
> > > > week which will have same patches and in same order as mentioned in
> > > > the cover letter. This will untie the development across different
> > > > architectures.
> > > >
> > > > Many thanks
> > > > Salil.
> > > 
> > > However, please get authorship info right. This claims patch has been
> > > codeveloped by Bernhard Beschow, xianglai li and yourself.
> > > Your patch claims a completely different list of authors
> > 
> > Yes, because those are the people who have developed the patches.
> > 
> > > with yourself being the only common author.
> > > Not nice.
> > 
> > I have already replied in the other thread. This patch has been
> > taken from the ARM patch-set sent in the year 2020.
> > 
> > I am not sure who is the other author and how he has contributed.
> > 
> > Co-developed-by usually points at main authors.
> > 
> 
> 
> If you are not sure then find out please.
> And to help you stop guessing at the rules:
> 
> Documentation/process/submitting-patches.rst
> 
>       Co-developed-by: states that the patch was co-created by multiple 
> developers;
>       it is used to give attribution to co-authors (in addition to the author
>       attributed by the From: tag) when several people work on a single 
> patch.  Since
>       Co-developed-by: denotes authorship, every Co-developed-by: must be 
> immediately
>       followed by a Signed-off-by: of the associated co-author.  Standard 
> sign-off
>       procedure applies, i.e. the ordering of Signed-off-by: tags should 
> reflect the
>       chronological history of the patch insofar as possible, regardless of 
> whether
>       the author is attributed via From: or Co-developed-by:.  Notably, the 
> last
>       Signed-off-by: must always be that of the developer submitting the 
> patch.

Note, that's a linux.git docs requirement you're pointing to,
not a QEMU one.

I don't think QEMU has historically gone about this level
of precise detail/strictness.

Nothing in the DCO requires every co-developer to add a S-o-B.
The person adding a S-o-B is attesting that they are confident
they have the rights to submit this. One way they can attain
this confidence is if the people they worked with add their own
S-o-B but that's not a hard requirement. *If* some co-developers
were working inside the same company and copyright is owned by
the company, it is reasonable to only have one S-o-B for the
person who finally submits it. That's a judgement call the person
submitting can make.

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 :|




reply via email to

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