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

[Michael S. Tsirkin]

On Tue, Sep 26, 2023 at 01:30:30PM +0100, Daniel P. Berrangé wrote:
> 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

We really should write the rules up btw.
And, I think it would be a really bad idea to use exactly
the same tag as linux with a slightly different set of rules.



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