[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: 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |