Pull request: u-boot-staging

let's see if the suggested approach work or there is need for an adjustment.

I have applied some general and network patches to u-boot-staging. Should I also send an "Applied to u-boot-staging" message to the mailing list and to the author ? Or this is done afterwards if and when the branch is pulled ?

git://www.denx.de/git/u-boot-staging sbabic at denx.de

Andreas Bie?mann (1):
tools/env: use lib/crc32.c directly

David Wagner (1):
new tool mkenvimage: generates an env image from an arbitrary
config file

Igor Grinberg (17):
env: clean environment.h checkpatch and code style
common: move extern char console_buffer[] to common.h
env: move extern default_environment[] to environment.h
env: move extern environment[] to environment.h
env: clean cmd_nvedit.c checkpatch and code style
env: clean env_nowhere.c checkpatch and code style
env: clean env_mgdisk.c checkpatch and code style
env: clean env_dataflash.c checkpatch and code style
env: clean env_onenand.c checkpatch and code style
env: clean env_nvram.c checkpatch and code style
env: clean env_mmc.c checkpatch and code style
env: clean env_embedded.c checkpatch and code style
env: clean env_eeprom.c checkpatch and code style
env: clean env_sf.c checkpatch and code style
env: clean env_flash.c checkpatch and code style
env: clean env_nand.c checkpatch and code style
env: clean env_common.c checkpatch and code style

Mike Frysinger (1):
net: rtl8109: drop unused !NET_MULTI driver

Simon Glass (3):
Define uintptr_t as long int to simplify printf() format strings Fix warnings in cmd_nvedit.c
sandbox: Fix warnings in hashtable.c

Wolfgang Grandegger (2):
smsc95xx: Fix MAC address programming
smsc95xx: Debug message cleanup

 Makefile                     |    2 +-
 arch/arm/lib/board.c         |    4 -
 board/amcc/yucca/cmd_yucca.c |    1 -
 board/eltec/bab7xx/misc.c    |    1 -
 board/eltec/elppc/misc.c     |    1 -
 board/eltec/mhpc/mhpc.c      |    3 -
 board/hymod/input.c          |    3 -
 board/zeus/zeus.c            |    1 -
 common/cmd_bedbug.c          |    1 -
 common/cmd_dcr.c             |    1 -
 common/cmd_i2c.c             |    1 -
 common/cmd_mem.c             |    1 -
 common/cmd_nvedit.c          |  104 ++++++++---------
 common/cmd_pci.c             |    1 -
 common/env_common.c          |   52 +++------
 common/env_dataflash.c       |   34 ++----
 common/env_eeprom.c          |  104 +++++++---------
 common/env_embedded.c        |   47 ++++----
 common/env_flash.c           |  181 +++++++++++++---------------
 common/env_mgdisk.c          |    7 +-
 common/env_mmc.c             |   78 ++++---------
 common/env_nand.c            |  105 +++++++---------
 common/env_nowhere.c         |   12 +-
 common/env_nvram.c           |   26 ++--
 common/env_onenand.c         |   21 +---
 common/env_sf.c              |   51 +++-----
 common/hush.c                |    1 -
 common/modem.c               |    1 -
 drivers/net/Makefile         |    1 -
 drivers/net/rtl8019.c        |  271
------------------------------------------
 drivers/net/rtl8019.h        |  114 ------------------
 drivers/usb/eth/smsc95xx.c   |   16 +--
 include/command.h            |    3 +
 include/common.h             |    1 +
 include/compiler.h           |   12 +--
 include/dataflash.h          |    2 +
 include/environment.h        |   61 ++++++----
 lib/hashtable.c              |    8 +-
 tools/Makefile               |    5 +

 tools/env/Makefile           |    7 +-
 tools/envcrc.c               |    5 +-
 tools/mkenvimage.c           |  270
+++++++++++++++++++++++++++++++++++++++++
 42 files changed, 689 insertions(+), 932 deletions(-)
 delete mode 100644 drivers/net/rtl8019.c
 delete mode 100644 drivers/net/rtl8019.h
 create mode 100644 tools/mkenvimage.c

Dear Stefano Babic,

Quoted 7 lines · In message <[email protected]> you wrote:

let's see if the suggested approach work or there is need for an adjustment.

I have applied some general and network patches to u-boot-staging. Should I also send an "Applied to u-boot-staging" message to the mailing list and to the author ? Or this is done afterwards if and when the branch is pulled ?

I forgot this in my initial summary of the idea: yes, please send such information to the submitter and the list.

I just want to pull the branch, I won't go though it and send e-mails.

Quoted 83 lines

? git://www.denx.de/git/u-boot-staging sbabic at denx.de

Andreas Bie?mann (1):
? ? ? tools/env: use lib/crc32.c directly

David Wagner (1):
? ? ? new tool mkenvimage: generates an env image from an arbitrary config file

Igor Grinberg (17):
? ? ? env: clean environment.h checkpatch and code style ? ? ? common: move extern char console_buffer[] to common.h ? ? ? env: move extern default_environment[] to environment.h ? ? ? env: move extern environment[] to environment.h ? ? ? env: clean cmd_nvedit.c checkpatch and code style ? ? ? env: clean env_nowhere.c checkpatch and code style ? ? ? env: clean env_mgdisk.c checkpatch and code style ? ? ? env: clean env_dataflash.c checkpatch and code style ? ? ? env: clean env_onenand.c checkpatch and code style ? ? ? env: clean env_nvram.c checkpatch and code style ? ? ? env: clean env_mmc.c checkpatch and code style ? ? ? env: clean env_embedded.c checkpatch and code style ? ? ? env: clean env_eeprom.c checkpatch and code style ? ? ? env: clean env_sf.c checkpatch and code style ? ? ? env: clean env_flash.c checkpatch and code style ? ? ? env: clean env_nand.c checkpatch and code style ? ? ? env: clean env_common.c checkpatch and code style

Mike Frysinger (1):
? ? ? net: rtl8109: drop unused !NET_MULTI driver

Simon Glass (3):
? ? ? Define uintptr_t as long int to simplify printf() format strings ? ? ? Fix warnings in cmd_nvedit.c
? ? ? sandbox: Fix warnings in hashtable.c

Wolfgang Grandegger (2):
? ? ? smsc95xx: Fix MAC address programming
? ? ? smsc95xx: Debug message cleanup

?Makefile ? ? ? ? ? ? ? ? ? ? | ? ?2 +-
?arch/arm/lib/board.c ? ? ? ? | ? ?4 -
?board/amcc/yucca/cmd_yucca.c | ? ?1 -
?board/eltec/bab7xx/misc.c ? ?| ? ?1 -
?board/eltec/elppc/misc.c ? ? | ? ?1 -
?board/eltec/mhpc/mhpc.c ? ? ?| ? ?3 -
?board/hymod/input.c ? ? ? ? ?| ? ?3 -
?board/zeus/zeus.c ? ? ? ? ? ?| ? ?1 -
?common/cmd_bedbug.c ? ? ? ? ?| ? ?1 -
?common/cmd_dcr.c ? ? ? ? ? ? | ? ?1 -
?common/cmd_i2c.c ? ? ? ? ? ? | ? ?1 -
?common/cmd_mem.c ? ? ? ? ? ? | ? ?1 -
?common/cmd_nvedit.c ? ? ? ? ?| ?104 ++++++++---------
?common/cmd_pci.c ? ? ? ? ? ? | ? ?1 -
?common/env_common.c ? ? ? ? ?| ? 52 +++------
?common/env_dataflash.c ? ? ? | ? 34 ++----
?common/env_eeprom.c ? ? ? ? ?| ?104 +++++++---------
?common/env_embedded.c ? ? ? ?| ? 47 ++++----
?common/env_flash.c ? ? ? ? ? | ?181 +++++++++++++---------------
?common/env_mgdisk.c ? ? ? ? ?| ? ?7 +-
?common/env_mmc.c ? ? ? ? ? ? | ? 78 ++++---------
?common/env_nand.c ? ? ? ? ? ?| ?105 +++++++---------
?common/env_nowhere.c ? ? ? ? | ? 12 +-
?common/env_nvram.c ? ? ? ? ? | ? 26 ++--
?common/env_onenand.c ? ? ? ? | ? 21 +---
?common/env_sf.c ? ? ? ? ? ? ?| ? 51 +++-----
?common/hush.c ? ? ? ? ? ? ? ?| ? ?1 -
?common/modem.c ? ? ? ? ? ? ? | ? ?1 -
?drivers/net/Makefile ? ? ? ? | ? ?1 -
?drivers/net/rtl8019.c ? ? ? ?| ?271
------------------------------------------
?drivers/net/rtl8019.h ? ? ? ?| ?114 ------------------
?drivers/usb/eth/smsc95xx.c ? | ? 16 +--
?include/command.h ? ? ? ? ? ?| ? ?3 +
?include/common.h ? ? ? ? ? ? | ? ?1 +
?include/compiler.h ? ? ? ? ? | ? 12 +--
?include/dataflash.h ? ? ? ? ?| ? ?2 +
?include/environment.h ? ? ? ?| ? 61 ++++++----
?lib/hashtable.c ? ? ? ? ? ? ?| ? ?8 +-
?tools/Makefile ? ? ? ? ? ? ? | ? ?5 +
?tools/env/Makefile ? ? ? ? ? | ? ?7 +-
?tools/envcrc.c ? ? ? ? ? ? ? | ? ?5 +-
?tools/mkenvimage.c ? ? ? ? ? | ?270

Quoted 5 lines

+++++++++++++++++++++++++++++++++++++++++
?42 files changed, 689 insertions(+), 932 deletions(-) ?delete mode 100644 drivers/net/rtl8019.c ?delete mode 100644 drivers/net/rtl8019.h ?create mode 100644 tools/mkenvimage.c

Sorry, but this doesn't work for me:

Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile Auto-merging common/cmd_mem.c
Auto-merging common/cmd_nvedit.c
Auto-merging common/env_dataflash.c Auto-merging common/env_eeprom.c
Auto-merging common/env_flash.c
Auto-merging common/env_mmc.c
Auto-merging common/env_nand.c
Auto-merging common/env_nvram.c
Auto-merging common/env_onenand.c Auto-merging common/env_sf.c
Removing drivers/net/rtl8019.c
Removing drivers/net/rtl8019.h
Auto-merging lib/hashtable.c
CONFLICT (content): Merge conflict in lib/hashtable.c

Auto-merging tools/Makefile
Automatic merge failed; fix conflicts and then commit the result.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de In accord with UNIX philosophy, Perl gives you enough ?rope ?to ?hang yourself. ? ? ? ? ? ? ?- L. Wall & R. L. Schwartz, _Programming Perl_

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Hi Stefano,

Quoted 1 line

CONFLICT (content): Merge conflict in lib/hashtable.c

For this conflict I am sending a V4 patch to the list.

I forgot this in my initial summary of the idea: yes, please send such information to the submitter and the list.

I just want to pull the branch, I won't go though it and send e-mails.

Quoted 2 lines · Wolfgang Denk

I forgot this in my initial summary of the idea: yes, please send such information to the submitter and the list.

Ok, done.

Quoted 2 lines

I just want to pull the branch, I won't go though it and send e-mails.

Rebased and tested on current u-boot master.

The following changes since commit f9342e2c3e81d62e42393c0c1a8179c309ef3a20:

Merge branch 'sr at denx.de' of git://git.denx.de/u-boot-staging
(2011-11-21 22:11:05 +0100)

are available in the git repository at:

git://git.denx.de/u-boot-staging sbabic at denx.de

Andreas Bie?mann (1):
tools/env: use lib/crc32.c directly

David Wagner (1):
new tool mkenvimage: generates an env image from an arbitrary
config file

Igor Grinberg (17):
env: clean environment.h checkpatch and code style
common: move extern char console_buffer[] to common.h
env: move extern default_environment[] to environment.h
env: move extern environment[] to environment.h
env: clean cmd_nvedit.c checkpatch and code style
env: clean env_nowhere.c checkpatch and code style
env: clean env_mgdisk.c checkpatch and code style
env: clean env_dataflash.c checkpatch and code style
env: clean env_onenand.c checkpatch and code style
env: clean env_nvram.c checkpatch and code style
env: clean env_mmc.c checkpatch and code style
env: clean env_embedded.c checkpatch and code style
env: clean env_eeprom.c checkpatch and code style
env: clean env_sf.c checkpatch and code style
env: clean env_flash.c checkpatch and code style
env: clean env_nand.c checkpatch and code style
env: clean env_common.c checkpatch and code style

Mike Frysinger (1):
net: rtl8109: drop unused !NET_MULTI driver

Simon Glass (3):
Define uintptr_t as long int to simplify printf() format strings Fix warnings in cmd_nvedit.c
sandbox: Fix warnings in hashtable.c

Wolfgang Grandegger (2):
smsc95xx: Fix MAC address programming
smsc95xx: Debug message cleanup

bertrand.cachet at heig-vd.ch (1):
Improve Power Management in SMC911X driver.

 Makefile                     |    2 +-
 arch/arm/lib/board.c         |    4 -
 board/amcc/yucca/cmd_yucca.c |    1 -
 board/eltec/bab7xx/misc.c    |    1 -
 board/eltec/elppc/misc.c     |    1 -
 board/eltec/mhpc/mhpc.c      |    3 -
 board/hymod/input.c          |    3 -
 board/zeus/zeus.c            |    1 -
 common/cmd_bedbug.c          |    1 -
 common/cmd_dcr.c             |    1 -
 common/cmd_i2c.c             |    1 -
 common/cmd_mem.c             |    1 -
 common/cmd_nvedit.c          |  104 ++++++++---------
 common/cmd_pci.c             |    1 -
 common/env_common.c          |   52 +++------
 common/env_dataflash.c       |   34 ++----
 common/env_eeprom.c          |  104 +++++++---------
 common/env_embedded.c        |   47 ++++----
 common/env_flash.c           |  181 +++++++++++++---------------
 common/env_mgdisk.c          |    7 +-
 common/env_mmc.c             |   78 ++++---------
 common/env_nand.c            |  105 +++++++---------
 common/env_nowhere.c         |   12 +-
 common/env_nvram.c           |   26 ++--
 common/env_onenand.c         |   21 +---
 common/env_sf.c              |   51 +++-----
 common/hush.c                |    1 -
 common/modem.c               |    1 -
 drivers/net/Makefile         |    1 -
 drivers/net/rtl8019.c        |  271
------------------------------------------
 drivers/net/rtl8019.h        |  114 ------------------
 drivers/net/smc911x.h        |    7 +-
 drivers/usb/eth/smsc95xx.c   |   16 +--
 include/command.h            |    3 +
 include/common.h             |    1 +
 include/compiler.h           |   12 +--
 include/dataflash.h          |    2 +
 include/environment.h        |   61 ++++++----
 lib/hashtable.c              |   10 +-
 tools/Makefile               |    5 +

 tools/env/Makefile           |    7 +-
 tools/envcrc.c               |    5 +-
 tools/mkenvimage.c           |  270
+++++++++++++++++++++++++++++++++++++++++
 43 files changed, 695 insertions(+), 935 deletions(-)
 delete mode 100644 drivers/net/rtl8019.c
 delete mode 100644 drivers/net/rtl8019.h
 create mode 100644 tools/mkenvimage.c

Hi Stefano,

Probably, it is too late now, but there is no your Signed-off-by on any of the patches from sbabic at denx.de branch on u-boot-staging. If you use "git am" for applying patches, then you should also add "-s" flag.

Quoted 2 lines · Igor Grinberg

Hi Stefano,

Hi Igor,

Quoted 3 lines

Probably, it is too late now, but there is no your Signed-off-by on any of the patches from sbabic at denx.de branch on u-boot-staging. If you use "git am" for applying patches, then you should also add "-s" flag.

I do not think it is correct, but I am asking to the ML and Wolfgang to be sure. I should add my Signed-off if I rearrange the patches or introduce some modifications that are not cosmetic.

Because I am not the author of the patches, I do not add my Signed-off, and I do the same for u-boot-imx, where I am the custodian. As far as I know, all custodians are doing in the same way.

Quoted 4 lines

Because I am not the author of the patches, I do not add my Signed-off, and I do the same for u-boot-imx, where I am the custodian. As far as I know, all custodians are doing in the same way.

I see... Is there a U-Boot policy regarding this somewhere?

Because in Linux every person involved in pushing patches should add an SOB to the commit message.

Dear Igor Grinberg,

Quoted 6 lines · In message <[email protected]> you wrote:

Quoted 4 lines

Because I am not the author of the patches, I do not add my Signed-off, and I do the same for u-boot-imx, where I am the custodian. As far as I know, all custodians are doing in the same way.

I see... Is there a U-Boot policy regarding this somewhere?

Nobody bothered yet to write down such a thing, so we all go on as we started some time in the past.

Quoted 2 lines

Because in Linux every person involved in pushing patches should add an SOB to the commit message.

The question is how you define "pushing".
"Documentation/SubmittingPatches" says:

|         By making a contribution to this project, I certify that:
| 
|         (a) The contribution was created in whole or in part by me and I
|             have the right to submit it under the open source license
|             indicated in the file; or
| 
|         (b) The contribution is based upon previous work that, to the best
|             of my knowledge, is covered under an appropriate open source
|             license and I have the right under that license to submit that
|             work with modifications, whether created in whole or in part
|             by me, under the same open source license (unless I am
|             permitted to submit under a different license), as indicated
|             in the file; or
| 
|         (c) The contribution was provided directly to me by some other
|             person who certified (a), (b) or (c) and I have not modified
|             it.
| 
|         (d) I understand and agree that this project and the contribution
|             are public and that a record of the contribution (including all
|             personal information I submit with it, including my sign-off) is
|             maintained indefinitely and may be redistributed consistent with
|             this project or the open source license(s) involved.
| 
| then you just add a line saying
| 
|         Signed-off-by: Random J Developer <[email protected]>

(a) and (b) don't apply here, and (d) is not relevant in this context. So the question is if (c) applies, or not.

My personal point of view is that someone who just applies a patch (without any changes) from the mailing list or from PatchWork does not have to sign it.

If it were the other way round, I would have a problem for example when I use "git pull" or "git merge" to apply commits from a custodian's repository - neither "git pull" nor "git merge" provide ways to sign such an action - not to mention that then I would have to sign all included commits, too.

But maybe I'm just misinterpreting...

Hi Wolfgang, Stefano,

Quoted 31 lines

The question is how you define "pushing".
"Documentation/SubmittingPatches" says:

|         By making a contribution to this project, I certify that:
| 
|         (a) The contribution was created in whole or in part by me and I
|             have the right to submit it under the open source license
|             indicated in the file; or
| 
|         (b) The contribution is based upon previous work that, to the best
|             of my knowledge, is covered under an appropriate open source
|             license and I have the right under that license to submit that
|             work with modifications, whether created in whole or in part
|             by me, under the same open source license (unless I am
|             permitted to submit under a different license), as indicated
|             in the file; or
| 
|         (c) The contribution was provided directly to me by some other
|             person who certified (a), (b) or (c) and I have not modified
|             it.
| 
|         (d) I understand and agree that this project and the contribution
|             are public and that a record of the contribution (including all
|             personal information I submit with it, including my sign-off) is
|             maintained indefinitely and may be redistributed consistent with
|             this project or the open source license(s) involved.
| 
| then you just add a line saying
| 
|         Signed-off-by: Random J Developer <[email protected]>

Quoted 2 lines

(a) and (b) don't apply here, and (d) is not relevant in this context. So the question is if (c) applies, or not.

Well, I think yes (c) applies here and if you look into the Linux git log, you will see that all patches applied by maintainers are also signed by them.

Quoted 2 lines · Igor Grinberg

Hi Wolfgang, Stefano,

Hi Igor,

to add maybe some confusion here I have now checked into U-Boot log and I see that at least one custodian (Paulraj, I have added now in CC) follows the Linux way.

Quoted 31 lines

Quoted 31 lines

The question is how you define "pushing".
"Documentation/SubmittingPatches" says:

| ? ? ? ? By making a contribution to this project, I certify that:
|
| ? ? ? ? (a) The contribution was created in whole or in part by me and I
| ? ? ? ? ? ? have the right to submit it under the open source license
| ? ? ? ? ? ? indicated in the file; or
|
| ? ? ? ? (b) The contribution is based upon previous work that, to the best
| ? ? ? ? ? ? of my knowledge, is covered under an appropriate open source
| ? ? ? ? ? ? license and I have the right under that license to submit that
| ? ? ? ? ? ? work with modifications, whether created in whole or in part
| ? ? ? ? ? ? by me, under the same open source license (unless I am
| ? ? ? ? ? ? permitted to submit under a different license), as indicated
| ? ? ? ? ? ? in the file; or
|
| ? ? ? ? (c) The contribution was provided directly to me by some other
| ? ? ? ? ? ? person who certified (a), (b) or (c) and I have not modified
| ? ? ? ? ? ? it.
|
| ? ? ? ? (d) I understand and agree that this project and the contribution
| ? ? ? ? ? ? are public and that a record of the contribution (including all
| ? ? ? ? ? ? personal information I submit with it, including my sign-off) is
| ? ? ? ? ? ? maintained indefinitely and may be redistributed consistent with
| ? ? ? ? ? ? this project or the open source license(s) involved.
|
| then you just add a line saying
|
| ? ? ? ? Signed-off-by: Random J Developer <[email protected]>

Quoted 6 lines

Quoted 2 lines

(a) and (b) don't apply here, and (d) is not relevant in this context. So the question is if (c) applies, or not.

Well, I think yes (c) applies here and if you look into the Linux git log, you will see that all patches applied by maintainers are also signed by them.

Reading (c), I can interprete as Igor does...

13) When to use Acked-by: and Cc:

The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path.

I think that makes the intent of (c) clear.

Dear Andy Fleming,

Quoted 6 lines · In message <CAKWjMd5N1ozpR2O4rWCzPpPzjbZL1xAT0sRhoDz61aSzZSXEyw@mail.gmail.com>…

13) When to use Acked-by: and Cc:

The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path.

Quoted 1 line

I think that makes the intent of (c) clear.

Yes, but to me "delivery path" means the path from where the patch has been developed through reviewers, other developers that change/improve it etc. until it hits it's destination and gets delivered to ... well, to where? In our case to that is the mailing list respective PatchWork. This is where we deliver our patches to. The delivery path ends there.

For my understanding, the delivery ends with *unique commit id* in some repository, which then can get pulled, but has history intact.

Nevertheless, it is a meter of choice, that should be made. I'm fine with any choice we will make.

Dear Igor Grinberg,

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 2 lines

For my understanding, the delivery ends with *unique commit id* in some repository, which then can get pulled, but has history intact.

But depending on the process, the initial commit id may or may not be the final one. Think for example about rebases that happen every now and then, even in custodian trees. And a commit ID in "some tree" is worth nothing if you cannot guarantee that this tree is publicly accessable guaranteed to exist forever.

Quoted 3 lines

Nevertheless, it is a meter of choice, that should be made. I'm fine with any choice we will make.

Me too. But it has to make sense.

Quoted 4 lines

Quoted 4 lines

|         (c) The contribution was provided directly to me by some other
|             person who certified (a), (b) or (c) and I have not modified
|             it.

Quoted 6 lines

Quoted 2 lines

(a) and (b) don't apply here, and (d) is not relevant in this context. So the question is if (c) applies, or not.

Well, I think yes (c) applies here and if you look into the Linux git log, you will see that all patches applied by maintainers are also signed by them.

Reading (c), I can interprete as Igor does...

Dear Stefano Babic,

Quoted 4 lines · In message <[email protected]> you wrote:

Quoted 4 lines

Quoted 4 lines

|         (c) The contribution was provided directly to me by some other
|             person who certified (a), (b) or (c) and I have not modified
|             it.

...

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

(a) and (b) don't apply here, and (d) is not relevant in this context. So the question is if (c) applies, or not.

Well, I think yes (c) applies here and if you look into the Linux git log, you will see that all patches applied by maintainers are also signed by them.

Quoted 1 line

Reading (c), I can interprete as Igor does...

I _can_ interpret that so as well, but does it make sense?

By that logic _all_ commits in the Linux kernel must have the SoB of Linus Torvalds. Do they?

Quoted 5 lines · Wolfgang Denk

Dear Stefano Babic,

Quoted 2 lines · In message <[email protected]> you wrote:

Quoted 2 lines

Quoted 2 lines

| (c) The contribution was provided directly to me by some

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

| person who certified (a), (b) or (c) and I have not

Quoted 3 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

| it.

...

Quoted 1 line

Quoted 1 line

Quoted 1 line

(a) and (b) don't apply here, and (d) is not relevant in this

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

So the question is if (c) applies, or not.

Well, I think yes (c) applies here and if you look into the Linux git log, you will see that all patches applied by maintainers are also signed by them.

Quoted 6 lines

Quoted 1 line

Reading (c), I can interprete as Igor does...

I _can_ interpret that so as well, but does it make sense?

By that logic _all_ commits in the Linux kernel must have the SoB of Linus Torvalds. Do they?

No they should not.
As for my understanding, the delivery path ends with the repository from which the pull process starts.
That is, the repository that has the *commit id* first set and then it is not changed, because pull requests keep the history intact. This is the reason, why Linus Torvalds do not sign each patch pulled from others with git pull.

Quoted 24 lines · On Nov 24, 2011 5:48 PM, "Igor Grinberg" <grinberg at compulab.co.il…

Quoted 15 lines · Wolfgang Denk

Dear Stefano Babic,

Quoted 4 lines · In message <4ECD25EA.1020508 at denx.de <mailto:[email protected]>> you…

Quoted 4 lines

Quoted 4 lines

|         (c) The contribution was provided directly to me by some other
|             person who certified (a), (b) or (c) and I have not modified
|             it.

...

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

(a) and (b) don't apply here, and (d) is not relevant in this context. So the question is if (c) applies, or not.

Well, I think yes (c) applies here and if you look into the Linux git log, you will see that all patches applied by maintainers are also signed by them.

Quoted 6 lines

Quoted 1 line

Reading (c), I can interprete as Igor does...

I _can_ interpret that so as well, but does it make sense?

By that logic _all_ commits in the Linux kernel must have the SoB of Linus Torvalds. Do they?

Quoted 8 lines

No they should not.
As for my understanding, the delivery path ends with the repository from which the pull process starts.
That is, the repository that has the *commit id* first set and then it is not changed, because pull requests keep the history intact. This is the reason, why Linus Torvalds do not sign each patch pulled from others with git pull.

Isn't the committer field enough?

And what difference does it really make anyway?

Quoted 6 lines

That is, the repository that has the *commit id* first set and then it is not changed, because pull requests keep the history intact. This is the reason, why Linus Torvalds do not sign each patch pulled from others with git pull.

Isn't the committer field enough?

And what difference does it really make anyway?

Quoted 3 lines

By that logic _all_ commits in the Linux kernel must have the SoB of Linus Torvalds. Do they?

No they should not.
As for my understanding, the delivery path ends with the repository from which the pull process starts.

That is, the repository that has the *commit id* first set and then it is not changed, because pull requests keep the history intact. This is the reason, why Linus Torvalds do not sign each patch pulled from others with git pull.

Dear Igor Grinberg,

Quoted 4 lines · In message <[email protected]> you wrote:

Quoted 3 lines

By that logic _all_ commits in the Linux kernel must have the SoB of Linus Torvalds. Do they?

Quoted 3 lines

No they should not.
As for my understanding, the delivery path ends with the repository from which the pull process starts.

That makes no sense either. What about the case where the author provides (say, for convenience) a git repository where we can pull from, instead of applying the posting from the ML or PW?

Quoted 5 lines

That is, the repository that has the *commit id* first set and then it is not changed, because pull requests keep the history intact. This is the reason, why Linus Torvalds do not sign each patch pulled from others with git pull.

Hm... what's the difference then between pulling from a tree or cherry picking from it? What about rebasing a tree?

Sorry, but all this makes not much sense to me. No matter how you handle it, it seems a pretty arbitrary decision to me.

And in all these cases the code is not touched any more.

Quoted 7 lines

Quoted 3 lines

As for my understanding, the delivery path ends with the repository from which the pull process starts.

That makes no sense either. What about the case where the author provides (say, for convenience) a git repository where we can pull from, instead of applying the posting from the ML or PW?

Well, I don't see how this is different from the custodian case, except that contributor is not a custodian.

Quoted 2 lines

Hm... what's the difference then between pulling from a tree or cherry picking from it? What about rebasing a tree?

Cherry picking changes the commit id even if there are no conflicts and can be done only on one commit at a time.

Let me make it clear, I'm not arguing that one way is better then another. I just thought that we are following the Linux model, as there is no document describing, how this thing should be done.

Again, no rule - is kind of rule, but it would be nice to have a document describing this decision, so less questions will arise.

Dear Igor Grinberg,

Quoted 8 lines · In message <[email protected]> you wrote:

Quoted 7 lines

Quoted 3 lines

As for my understanding, the delivery path ends with the repository from which the pull process starts.

That makes no sense either. What about the case where the author provides (say, for convenience) a git repository where we can pull from, instead of applying the posting from the ML or PW?

Quoted 2 lines

Well, I don't see how this is different from the custodian case, except that contributor is not a custodian.

So would the custodian have to sign then, or not? If yes, how would he do in a convenient way (git pull does not provide a "-s" option or similar to auto-sign all pulled commits [which would not make sense to me anyway])? If no, then what is the difference between the git pull and - say - a git am ?

Quoted 6 lines

Quoted 3 lines

Hm... what's the difference then between pulling from a tree or cherry picking from it? What about rebasing a tree?

Cherry picking changes the commit id even if there are no conflicts and can be done only on one commit at a time.

I cannot see what is special with a commit id in the context of signing a patch, or not. My understanding is that the SCM is just an unrelated tool here, andw e could use SVN or even (ick!) CVS instead, and still the concept of Signed-off-by:s should and would work.

Quoted 5 lines

Let me make it clear, I'm not arguing that one way is better then another. I just thought that we are following the Linux model, as there is no document describing, how this thing should be done.

Is there a document that describes exactly how this is be done for Linux? So far, all our conclusions appear to be derived from observations.

Quoted 3 lines

Again, no rule - is kind of rule, but it would be nice to have a document describing this decision, so less questions will arise.

Agreed. Does Linux have such a thing? [I could not find anything that goes into more detail than the SP file, which IMO is not really clear about that.]