[RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Liam Girdwood]

I'd like to gather some clarification wrt sign offs for alsa-driver to
alsa-kernel derived works.

Example in case: alsa-driver:i2c/uda1380.c was extensively modified to
become alsa-kernel:soc/codecs/uda1380.c

I submitted the derived driver with sign-off from 3 developers who had
worked on the derived work (Richard Purdie, Philipp Zabel and myself)
and the original alsa-driver:uda1380.c author (Giorgio Padrin) who was
not involved in creating the derived work.

I included Giorgio in the sign-off for the following reasons :-

1. There are sections of his original (non alsa-kernel) code and
algorithms within the derived work. This was to certify the origins of
*all* the code and algorithms within the derived driver as the original
driver only existed within alsa-driver and hence none of it's code had
been signed-off into the kernel.

Iirc, sign-off from Giorgio would not have been required if the original
driver was already part of the kernel. 

2. To give credit to where credit was due.


Takashi, Jaroslav, could you guys clarify the sign-off relationship
between alsa-driver -> alsa-kernel (inc derived works). I assume
original work from alsa-driver can be pushed into alsa-kernel due to
it's original sign-off ?

If original author sign-off is not required for this situation, I can
resubmit the code.

Many thanks

Liam



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Takashi Iwai]

At Thu, 15 Mar 2007 17:30:20 +0000,
Liam Girdwood wrote:
> 
> I'd like to gather some clarification wrt sign offs for alsa-driver to
> alsa-kernel derived works.
> 
> Example in case: alsa-driver:i2c/uda1380.c was extensively modified to
> become alsa-kernel:soc/codecs/uda1380.c
> 
> I submitted the derived driver with sign-off from 3 developers who had
> worked on the derived work (Richard Purdie, Philipp Zabel and myself)
> and the original alsa-driver:uda1380.c author (Giorgio Padrin) who was
> not involved in creating the derived work.
> 
> I included Giorgio in the sign-off for the following reasons :-
> 
> 1. There are sections of his original (non alsa-kernel) code and
> algorithms within the derived work. This was to certify the origins of
> *all* the code and algorithms within the derived driver as the original
> driver only existed within alsa-driver and hence none of it's code had
> been signed-off into the kernel.
> 
> Iirc, sign-off from Giorgio would not have been required if the original
> driver was already part of the kernel. 
> 
> 2. To give credit to where credit was due.
> 
> 
> Takashi, Jaroslav, could you guys clarify the sign-off relationship
> between alsa-driver -> alsa-kernel (inc derived works). I assume
> original work from alsa-driver can be pushed into alsa-kernel due to
> it's original sign-off ?

 From my understanding, the sign-off is a kind of approvals.
The patch author needs to sign off first, then the people who review
and approve the patch sign off in the next.

So, in your case, basically you don't need a sign-off by Giorgio since
"the patch" you wrote is different from his original one.

> If original author sign-off is not required for this situation, I can
> resubmit the code.

I don't think resubmission is needed.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Giorgio Padrin]

Il giorno ven, 16/03/2007 alle 12.56 +0100, Takashi Iwai ha scritto:
> At Thu, 15 Mar 2007 17:30:20 +0000,
> Liam Girdwood wrote:
> > 
> > I'd like to gather some clarification wrt sign offs for alsa-driver to
> > alsa-kernel derived works.
> > 
> > Example in case: alsa-driver:i2c/uda1380.c was extensively modified to
> > become alsa-kernel:soc/codecs/uda1380.c
> > 
> > I submitted the derived driver with sign-off from 3 developers who had
> > worked on the derived work (Richard Purdie, Philipp Zabel and myself)
> > and the original alsa-driver:uda1380.c author (Giorgio Padrin) who was
> > not involved in creating the derived work.
> > 
> > I included Giorgio in the sign-off for the following reasons :-
> > 
> > 1. There are sections of his original (non alsa-kernel) code and
> > algorithms within the derived work. This was to certify the origins of
> > *all* the code and algorithms within the derived driver as the original
> > driver only existed within alsa-driver and hence none of it's code had
> > been signed-off into the kernel.
> > 
> > Iirc, sign-off from Giorgio would not have been required if the original
> > driver was already part of the kernel. 
> > 
> > 2. To give credit to where credit was due.
> > 
> > 
> > Takashi, Jaroslav, could you guys clarify the sign-off relationship
> > between alsa-driver -> alsa-kernel (inc derived works). I assume
> > original work from alsa-driver can be pushed into alsa-kernel due to
> > it's original sign-off ?
> 
>  From my understanding, the sign-off is a kind of approvals.
> The patch author needs to sign off first, then the people who review
> and approve the patch sign off in the next.
> 
> So, in your case, basically you don't need a sign-off by Giorgio since
> "the patch" you wrote is different from his original one.
> 
> > If original author sign-off is not required for this situation, I can
> > resubmit the code.
> 
> I don't think resubmission is needed.

As long as that sign-off-by line is expunged from the submission, cause
not coming from me. For the health of the process.

giorgio


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Takashi Iwai]

At Sun, 18 Mar 2007 07:51:45 +0100,
Giorgio Padrin wrote:
> 
> Il giorno ven, 16/03/2007 alle 12.56 +0100, Takashi Iwai ha scritto:
> > At Thu, 15 Mar 2007 17:30:20 +0000,
> > Liam Girdwood wrote:
> > > 
> > > I'd like to gather some clarification wrt sign offs for alsa-driver to
> > > alsa-kernel derived works.
> > > 
> > > Example in case: alsa-driver:i2c/uda1380.c was extensively modified to
> > > become alsa-kernel:soc/codecs/uda1380.c
> > > 
> > > I submitted the derived driver with sign-off from 3 developers who had
> > > worked on the derived work (Richard Purdie, Philipp Zabel and myself)
> > > and the original alsa-driver:uda1380.c author (Giorgio Padrin) who was
> > > not involved in creating the derived work.
> > > 
> > > I included Giorgio in the sign-off for the following reasons :-
> > > 
> > > 1. There are sections of his original (non alsa-kernel) code and
> > > algorithms within the derived work. This was to certify the origins of
> > > *all* the code and algorithms within the derived driver as the original
> > > driver only existed within alsa-driver and hence none of it's code had
> > > been signed-off into the kernel.
> > > 
> > > Iirc, sign-off from Giorgio would not have been required if the original
> > > driver was already part of the kernel. 
> > > 
> > > 2. To give credit to where credit was due.
> > > 
> > > 
> > > Takashi, Jaroslav, could you guys clarify the sign-off relationship
> > > between alsa-driver -> alsa-kernel (inc derived works). I assume
> > > original work from alsa-driver can be pushed into alsa-kernel due to
> > > it's original sign-off ?
> > 
> >  From my understanding, the sign-off is a kind of approvals.
> > The patch author needs to sign off first, then the people who review
> > and approve the patch sign off in the next.
> > 
> > So, in your case, basically you don't need a sign-off by Giorgio since
> > "the patch" you wrote is different from his original one.
> > 
> > > If original author sign-off is not required for this situation, I can
> > > resubmit the code.
> > 
> > I don't think resubmission is needed.
> 
> As long as that sign-off-by line is expunged from the submission, cause
> not coming from me. For the health of the process.

Or, please check the patch and give a sign-off, so everyhing will be
happy again.

As mentioned, a sign-off doesn't mean that the patch is from yours at
all.  It means that it's reviewed and confirmed as a patch for merge.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Richard Purdie]

On Mon, 2007-03-19 at 11:31 +0100, Takashi Iwai wrote:
> At Sun, 18 Mar 2007 07:51:45 +0100,
> Giorgio Padrin wrote:
> > Il giorno ven, 16/03/2007 alle 12.56 +0100, Takashi Iwai ha scritto:
> > > 
> > > So, in your case, basically you don't need a sign-off by Giorgio since
> > > "the patch" you wrote is different from his original one.
> > > 
> > > > If original author sign-off is not required for this situation, I can
> > > > resubmit the code.
> > > 
> > > I don't think resubmission is needed.
> > 
> > As long as that sign-off-by line is expunged from the submission, cause
> > not coming from me. For the health of the process.
> 
> Or, please check the patch and give a sign-off, so everyhing will be
> happy again.
> 
> As mentioned, a sign-off doesn't mean that the patch is from yours at
> all.  It means that it's reviewed and confirmed as a patch for merge.

That would be Acked-by where you review it and just confirm its ok by
you.

Signed-off-by means the patch passed through the hands of the person on
its way into mainline. The SoC patches that had my signed-off-by line
were correct as I'd passed them to Liam who collected them, then pushed
them upstream - the patches passed through both our hands.

In this case (as I understand it), Giorgio wrote some of the code it was
based on and therefore should get a mention in the commit message and
headers of the files concerned. If he agrees with the code, he can also
Ack it. He hasn't been directly part of the chain of submission though.

Regards,

Richard



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Takashi Iwai]

At Mon, 19 Mar 2007 10:53:48 +0000,
Richard Purdie wrote:
> 
> On Mon, 2007-03-19 at 11:31 +0100, Takashi Iwai wrote:
> > At Sun, 18 Mar 2007 07:51:45 +0100,
> > Giorgio Padrin wrote:
> > > Il giorno ven, 16/03/2007 alle 12.56 +0100, Takashi Iwai ha scritto:
> > > > 
> > > > So, in your case, basically you don't need a sign-off by Giorgio since
> > > > "the patch" you wrote is different from his original one.
> > > > 
> > > > > If original author sign-off is not required for this situation, I can
> > > > > resubmit the code.
> > > > 
> > > > I don't think resubmission is needed.
> > > 
> > > As long as that sign-off-by line is expunged from the submission, cause
> > > not coming from me. For the health of the process.
> > 
> > Or, please check the patch and give a sign-off, so everyhing will be
> > happy again.
> > 
> > As mentioned, a sign-off doesn't mean that the patch is from yours at
> > all.  It means that it's reviewed and confirmed as a patch for merge.
> 
> That would be Acked-by where you review it and just confirm its ok by
> you.
> 
> Signed-off-by means the patch passed through the hands of the person on
> its way into mainline. The SoC patches that had my signed-off-by line
> were correct as I'd passed them to Liam who collected them, then pushed
> them upstream - the patches passed through both our hands.
> 
> In this case (as I understand it), Giorgio wrote some of the code it was
> based on and therefore should get a mention in the commit message and
> headers of the files concerned. If he agrees with the code, he can also
> Ack it. He hasn't been directly part of the chain of submission though.

In the exact defintion, yes, you're correct.

But, a patch can be submitted from multiple paths, i.e. I may receive
the very same patch from multiple persons at the same time.  In that
case, Signed-off-by isn't completely wrong (except for the time-line
:-)

Note that we cannot modify the commit log on public Git or HG tree
easily, and sign-offs are in commit logs.  So, removing a sign-off
from the public tree should be the very last choice.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Richard Purdie]

On Mon, 2007-03-19 at 12:04 +0100, Takashi Iwai wrote:
> At Mon, 19 Mar 2007 10:53:48 +0000, Richard Purdie wrote:
> > That would be Acked-by where you review it and just confirm its ok by
> > you.
> > 
> > Signed-off-by means the patch passed through the hands of the person on
> > its way into mainline. The SoC patches that had my signed-off-by line
> > were correct as I'd passed them to Liam who collected them, then pushed
> > them upstream - the patches passed through both our hands.
> > 
> > In this case (as I understand it), Giorgio wrote some of the code it was
> > based on and therefore should get a mention in the commit message and
> > headers of the files concerned. If he agrees with the code, he can also
> > Ack it. He hasn't been directly part of the chain of submission though.
> 
> In the exact defintion, yes, you're correct.
> 
> But, a patch can be submitted from multiple paths, i.e. I may receive
> the very same patch from multiple persons at the same time.  In that
> case, Signed-off-by isn't completely wrong (except for the time-line
> :-)
> 
> Note that we cannot modify the commit log on public Git or HG tree
> easily, and sign-offs are in commit logs.  So, removing a sign-off
> from the public tree should be the very last choice.

I understand that. I'm mainly concerned with people getting it right in
future which I think it why Liam asked the original question. For the
reason you mention, that specific case might need a different handling
for the reason you've mentioned.

Cheers,

Richard


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Giorgio Padrin]

Il giorno lun, 19/03/2007 alle 11.13 +0000, Richard Purdie ha scritto:
> On Mon, 2007-03-19 at 12:04 +0100, Takashi Iwai wrote:
> > At Mon, 19 Mar 2007 10:53:48 +0000, Richard Purdie wrote:
> > > That would be Acked-by where you review it and just confirm its ok by
> > > you.
> > > 
> > > Signed-off-by means the patch passed through the hands of the person on
> > > its way into mainline. The SoC patches that had my signed-off-by line
> > > were correct as I'd passed them to Liam who collected them, then pushed
> > > them upstream - the patches passed through both our hands.
> > > 
> > > In this case (as I understand it), Giorgio wrote some of the code it was
> > > based on and therefore should get a mention in the commit message and
> > > headers of the files concerned. If he agrees with the code, he can also
> > > Ack it. He hasn't been directly part of the chain of submission though.
> > 
> > In the exact defintion, yes, you're correct.
> > 
> > But, a patch can be submitted from multiple paths, i.e. I may receive
> > the very same patch from multiple persons at the same time.  In that
> > case, Signed-off-by isn't completely wrong (except for the time-line
> > :-)
> > 
> > Note that we cannot modify the commit log on public Git or HG tree
> > easily, and sign-offs are in commit logs.  So, removing a sign-off
> > from the public tree should be the very last choice.
> 
> I understand that. I'm mainly concerned with people getting it right in
> future which I think it why Liam asked the original question. For the
> reason you mention, that specific case might need a different handling
> for the reason you've mentioned.

I'm in a sense amazed at divagations in this thread.
I'm interested that sign-off annotations come from their stated
signers :D. This should be a basic fact in the process, ça va sans dire.

For the rest, this case is no more than a minor accident, not worth the
time of nobody in correcting, if it would be too complicated. Takashi,
feel free to pass beyond it.

giorgio




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [RFC] Sign offs for alsa-driver -> alsa-kernel derived works.

[Takashi Iwai]

At Mon, 19 Mar 2007 15:02:30 +0100,
Giorgio Padrin wrote:
> 
> Il giorno lun, 19/03/2007 alle 11.13 +0000, Richard Purdie ha scritto:
> > On Mon, 2007-03-19 at 12:04 +0100, Takashi Iwai wrote:
> > > At Mon, 19 Mar 2007 10:53:48 +0000, Richard Purdie wrote:
> > > > That would be Acked-by where you review it and just confirm its ok by
> > > > you.
> > > > 
> > > > Signed-off-by means the patch passed through the hands of the person on
> > > > its way into mainline. The SoC patches that had my signed-off-by line
> > > > were correct as I'd passed them to Liam who collected them, then pushed
> > > > them upstream - the patches passed through both our hands.
> > > > 
> > > > In this case (as I understand it), Giorgio wrote some of the code it was
> > > > based on and therefore should get a mention in the commit message and
> > > > headers of the files concerned. If he agrees with the code, he can also
> > > > Ack it. He hasn't been directly part of the chain of submission though.
> > > 
> > > In the exact defintion, yes, you're correct.
> > > 
> > > But, a patch can be submitted from multiple paths, i.e. I may receive
> > > the very same patch from multiple persons at the same time.  In that
> > > case, Signed-off-by isn't completely wrong (except for the time-line
> > > :-)
> > > 
> > > Note that we cannot modify the commit log on public Git or HG tree
> > > easily, and sign-offs are in commit logs.  So, removing a sign-off
> > > from the public tree should be the very last choice.
> > 
> > I understand that. I'm mainly concerned with people getting it right in
> > future which I think it why Liam asked the original question. For the
> > reason you mention, that specific case might need a different handling
> > for the reason you've mentioned.
> 
> I'm in a sense amazed at divagations in this thread.
> I'm interested that sign-off annotations come from their stated
> signers :D. This should be a basic fact in the process, ça va sans dire.
> 
> For the rest, this case is no more than a minor accident, not worth the
> time of nobody in correcting, if it would be too complicated. Takashi,
> feel free to pass beyond it.

OK, thanks.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV