On 03/15/16 16:06, Leif Lindholm wrote:
> Hi Evan,
>
> Thanks - I really appreciate you taking the time to summarise the
> situation.
>
> On Tue, Mar 15, 2016 at 01:14:39PM +0000, Evan Lloyd wrote:
>> I recently submitted some patches with fixes and improvements
>> derived from our work on the Juno platform.
>> Laszlo very politely queried my "sign off" of the patches which bore
>> Sami's name as author and gracefully suggested the proper "S-o-b"
>> style. Others have since queried my consequent strategy of
>> appending sign-offs from the whole team.
>>
>> The position is that Sami did the task of extracting changes from
>> our internal (offline) Subversion repository and merging them into a
>> Tianocore clone from GitHub. The Git "author" shows only that. (As
>> it happens, Sami was the producer of most of the changes, but that
>> is incidental.) We have neither time, nor inclination, to delve in
>> 4 years of offline development history simply to unravel the
>> original author and all contributors for each line of code.
>>
>> The main point is that as part of our contracts of employment we
>> assign all of our IP rights in the code to ARM. I assume other
>> companies have similar contractual terms over IP (everywhere I have
>> ever worked had). As tech lead I am tasked with evaluating the
>> team's code and submitting what is suitable to Tianocore, so ARM
>> effectively delegates the authority to release that (ARM) IP to me.
>> That is, ARM owns the code and gifts it to Tianocore; an individual
>> employee is only involved as a paid agent of ARM. Obviously
>> commits and submissions from an ARM e-mail address cannot be
>> personal contributions, so residual rights as author are not
>> relevant.
>>
>> However, the current "S-o-b" semantics on the list seems to be based
>> on purely personal contributions. That takes no account of work
>> done by a team within an organisation, or the fact that not
>> everybody in a team need interact directly with Git.
>>
>> So, can we come to some agreement about how that (corporate) sign
>> off is to be indicated, and what it is intended to achieve, anyway,
>> given that EDK2 contributors are members of UEFI?
>>
>> (NOTE: This is not about an author's right to the IP, which is
>> retained. It is about the meaning of authorship and sign-off by an
>> individual, of code generated at the expense of an organisation.)
>
> So, I think we have two separate items to resolve:
> 1) What is the appropriate sign-off for patches being exported from a
> previously not upstreamed internal development track.
> 2) What is the appropriate way for new developments to be contributed.
>
> Clearly the former should be given some leeway regardless of what the
> consensus for 2) is. I cannot believe this is an unusual situation,
> and it would be good to have a clearly defined (and agreed on) way to
> handle upstreaming of code previously maintained in internal
> repositories over an extended period.
>
> For what it's worth, I don't strongly oppose your view, but it looks
> unusual, so I do understand Laszlos reaction (my instinctive one was
> similar).
>
> The default Contribution.txt copied across the different modules does
> not appear to contradict your view, but I fear it may be possible to
> read it either way depending on your expectations.
>
> What I'm really looking for is (as I've hinted before on the list)
> some better codification of the development model used in this
> community. So I would appreciate input from more people.
My only request is that the "Author:" git metadata header be matched by
the first Signed-off-by tag. If it is *already* known that persons X, Y
and Z have worked on patch P, and X was the first among them, then the
"Author:" header should state X, and there should be three S-o-b's, for
X, Y and Z, with X in the first position.
I'm not suggesting that ARM determine the exact set of authors {X, Y, Z}
for every single patch P (at least as long as they are sure that that
set, whatever it is exactly, is covered contractually). What I request
is that if subset {X, Y} is *already* known, and being exposed on the
patch, then it be please reflected correctly, without contradictions.
Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
