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

Re: [Xen-devel] [PATCH] shim: Fix generation of compat/callback.i: allow redef of OBJECT vars





On Thu, Jul 19, 2018 at 12:34 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
On Thu, 19 Jul 2018, Jan Beulich wrote:
> >>> Stefano Stabellini <sstabellini@xxxxxxxxxx> 07/19/18 8:49 PM >>>
> >On Thu, 19 Jul 2018, Jan Beulich wrote:
> >> >>> Stefano Stabellini <sstabellini@xxxxxxxxxx> 07/19/18 7:00 PM >>>
> >> >On Thu, 19 Jul 2018, Jan Beulich wrote:
> >> >> > Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
> >> >> > ---
> >> >> > Please use my gmail address for any correspondence to me.
> >> >>
> >> >> I think it is generally considered bad practice to have From: and S-o-b
> >> >> differ.
> >> >
> >> >Why? That is perfectly fine. Signed-off-by is about copyright of the
> >> >code while From: is about authorship.
> >>
> >> Well, in this particular case Christopher had even asked that communication
> >> to go to the mail address he sent from. How is anyone going to know that if
> >> judging just from the eventual commit in git?
> >
> >Yeah, that bit of information is lost in the commit message,
> >unfortunately. At that point, the patch is already committed, so it is
> >usually not a big deal.
>
> What if there is an issue with the change, or simply a question about it?
> I'd expect to be able to get in touch with the author by using the provided
> email address, at least if the commit isn't overly old yet.

Thinking about it, the From: email address will end up in the Author:
field of the commit. So actually, the information will be retained.

Thanks for the group input on the From/Author and S-o-b identifiers.

Context on the constraints which lead to the structure of my original message on this thread:

* Email message source:

My messages are sent to the list from my gmail account as that's the one I have easiest access to from my development environment. Shouldn't be a concern as I'm easily reachable there and as Stefano pointed out, inclusion of an alternate 'From:' in within the message body is enough to change the git 'Author' if the patch is merged.

* Commit Author:

I can provide either address for the From/Author address for the commit.

My preference is for it being the address I am reliably reachable at -- which would be my gmail account as noted. My reachability at this email address has exceeded that of any other email address I have ever had, surviving multiple changes of organizational affiliation.

* Commit Signed-off-by:

I have a legal requirement to ensure that copyright is attributed for the work, and I have used the S-o-b address to do so.  In the patch I sent, the email address provided for the S-o-b is under the administrative control of the legal owner of the copyright, which seems appropriate for it.

I could change the S-o-b to match the From/Author, and add further language to the commit message to clarify copyright attribution, but that seems incorrect and would require further effort to support any automation for eg. harvesting community contribution statistics.

Re: Jan's feedback on the patch content:

The hint to CFLAGS was helpful, thanks, as this double define is indeed being triggered when CFLAGS is not cleared, so: this patch isn't necessary.

I still haven't quite determined why a top level "make install" triggers a "make -C xen-root/xen distclean", which then causes further compilation to be performed, in what should be an install-only step, which made this other behaviour visible (since in the cross-compile system I'm working with, CFLAGS is being explicitly cleared for the "make" but happened not to be for "make install").

It's also been brought to my attention that this isn't the first time this undefine has been proposed on this list -- so apologies for the revisit.

thanks,

Christopher


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.