* [U-Boot] [GIT PULL] Pull request u-boot-staging
@ 2011-12-09 13:50 Stefano Babic
2011-12-10 21:43 ` Wolfgang Denk
0 siblings, 1 reply; 29+ messages in thread
From: Stefano Babic @ 2011-12-09 13:50 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
please pull from u-boot-staging, sbabic at denx.de. There is only one patch
in the list.
The following changes since commit c4eba6ec5c58083b38340724c006294c7a4fe2eb:
common/usb_kbd.c: fix bug introduced in commit 00b7d6e (2011-12-09
12:09:35 +0100)
are available in the git repository at:
git://www.denx.de/git/u-boot-staging sbabic at denx.de
Simon Glass (1):
Add board_pre_console_putc to deal with early console output
README | 17 +++++++++++++++++
common/console.c | 10 +++++++++-
include/common.h | 7 +++++++
3 files changed, 33 insertions(+), 1 deletions(-)
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [GIT PULL] Pull request u-boot-staging
2011-12-09 13:50 [U-Boot] [GIT PULL] Pull request u-boot-staging Stefano Babic
@ 2011-12-10 21:43 ` Wolfgang Denk
0 siblings, 0 replies; 29+ messages in thread
From: Wolfgang Denk @ 2011-12-10 21:43 UTC (permalink / raw)
To: u-boot
Dear Stefano Babic,
In message <4EE21228.7070700@denx.de> you wrote:
> Hi Wolfgang,
>
> please pull from u-boot-staging, sbabic at denx.de. There is only one patch
> in the list.
>
> The following changes since commit c4eba6ec5c58083b38340724c006294c7a4fe2eb:
>
> common/usb_kbd.c: fix bug introduced in commit 00b7d6e (2011-12-09
> 12:09:35 +0100)
>
> are available in the git repository at:
> git://www.denx.de/git/u-boot-staging sbabic at denx.de
>
> Simon Glass (1):
> Add board_pre_console_putc to deal with early console output
>
> README | 17 +++++++++++++++++
> common/console.c | 10 +++++++++-
> include/common.h | 7 +++++++
> 3 files changed, 33 insertions(+), 1 deletions(-)
Applied, thanks.
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
"Consistency requires you to be as ignorant today as you were a year
ago." - Bernard Berenson
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
@ 2011-11-23 7:37 Heiko Schocher
2011-11-23 20:26 ` Wolfgang Denk
0 siblings, 1 reply; 29+ messages in thread
From: Heiko Schocher @ 2011-11-23 7:37 UTC (permalink / raw)
To: u-boot
Hello Wolfgang,
The following changes since commit 5721385b187b3154c7768e6c182501022f4e2e45:
Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx (2011-11-08 07:44:52 +0100)
are available in the git repository at:
git://git.denx.de/u-boot-staging hs at denx.de
Anatolij Gustschin (13):
drivers/usb/musb/musb_hcd.c: Fix GCC 4.6 warning
drivers/mtd/onenand/samsung.c: Fix GCC 4.6 warning
board/ronetix/pm9263/pm9263.c: Fix GCC 4.6 warning
drivers/net/lan91c96.c: Fix GCC 4.6 warning
arch/arm/cpu/arm926ejs/omap/cpuinfo.c: Fix GCC 4.6 warnings
drivers/net/cs8900.c: Fix GCC 4.6 warning
board/lubbock/flash.c: Fix GCC 4.6 warnings
board/mx1ads/syncflash.c: Fix GCC 4.6 warnings
board/mx1ads/mx1ads.c: Fix GCC 4.6 warning
common/cmd_bootm.c: Fix GCC 4.6 warnings
net/bootp.c: Fix GCC 4.6 warning
board/xaeniax/flash.c: Fix GCC 4.6 warnings
drivers/net/dnet.c: Fix GCC 4.6 warnings
arch/arm/cpu/arm926ejs/omap/cpuinfo.c | 5 +++--
board/lubbock/flash.c | 7 +++----
board/mx1ads/mx1ads.c | 7 +++----
board/mx1ads/syncflash.c | 20 +++++++++-----------
board/ronetix/pm9263/pm9263.c | 13 ++++++-------
board/xaeniax/flash.c | 7 +++----
common/cmd_bootm.c | 3 ++-
drivers/mtd/onenand/samsung.c | 3 +--
drivers/net/cs8900.c | 11 +++++------
drivers/net/dnet.c | 12 +++++-------
drivers/net/lan91c96.c | 7 ++-----
drivers/usb/musb/musb_hcd.c | 3 +--
net/bootp.c | 3 ++-
13 files changed, 45 insertions(+), 56 deletions(-)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 7:37 [U-Boot] [GIT PULL] Pull request: u-boot-staging Heiko Schocher
@ 2011-11-23 20:26 ` Wolfgang Denk
0 siblings, 0 replies; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-23 20:26 UTC (permalink / raw)
To: u-boot
Dear Heiko Schocher,
In message <4ECCA2AC.1060800@denx.de> you wrote:
> Hello Wolfgang,
>
> The following changes since commit 5721385b187b3154c7768e6c182501022f4e2e45:
>
> Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx (2011-11-08 07:44:52 +0100)
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-staging hs at denx.de
>
> Anatolij Gustschin (13):
> drivers/usb/musb/musb_hcd.c: Fix GCC 4.6 warning
> drivers/mtd/onenand/samsung.c: Fix GCC 4.6 warning
> board/ronetix/pm9263/pm9263.c: Fix GCC 4.6 warning
> drivers/net/lan91c96.c: Fix GCC 4.6 warning
> arch/arm/cpu/arm926ejs/omap/cpuinfo.c: Fix GCC 4.6 warnings
> drivers/net/cs8900.c: Fix GCC 4.6 warning
> board/lubbock/flash.c: Fix GCC 4.6 warnings
> board/mx1ads/syncflash.c: Fix GCC 4.6 warnings
> board/mx1ads/mx1ads.c: Fix GCC 4.6 warning
> common/cmd_bootm.c: Fix GCC 4.6 warnings
> net/bootp.c: Fix GCC 4.6 warning
> board/xaeniax/flash.c: Fix GCC 4.6 warnings
> drivers/net/dnet.c: Fix GCC 4.6 warnings
>
> arch/arm/cpu/arm926ejs/omap/cpuinfo.c | 5 +++--
> board/lubbock/flash.c | 7 +++----
> board/mx1ads/mx1ads.c | 7 +++----
> board/mx1ads/syncflash.c | 20 +++++++++-----------
> board/ronetix/pm9263/pm9263.c | 13 ++++++-------
> board/xaeniax/flash.c | 7 +++----
> common/cmd_bootm.c | 3 ++-
> drivers/mtd/onenand/samsung.c | 3 +--
> drivers/net/cs8900.c | 11 +++++------
> drivers/net/dnet.c | 12 +++++-------
> drivers/net/lan91c96.c | 7 ++-----
> drivers/usb/musb/musb_hcd.c | 3 +--
> net/bootp.c | 3 ++-
> 13 files changed, 45 insertions(+), 56 deletions(-)
Applied, thanks.
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
"Spock, did you see the looks on their faces?"
"Yes, Captain, a sort of vacant contentment."
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
@ 2011-11-18 8:58 Stefano Babic
2011-11-21 21:10 ` Wolfgang Denk
0 siblings, 1 reply; 29+ messages in thread
From: Stefano Babic @ 2011-11-18 8:58 UTC (permalink / raw)
To: u-boot
Wolfgang,
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 ?
The following changes since commit 5721385b187b3154c7768e6c182501022f4e2e45:
Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx (2011-11-08
07:44:52 +0100)
are available in the git repository at:
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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-18 8:58 Stefano Babic
@ 2011-11-21 21:10 ` Wolfgang Denk
2011-11-22 5:06 ` Simon Glass
2011-11-22 8:59 ` Stefano Babic
0 siblings, 2 replies; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-21 21:10 UTC (permalink / raw)
To: u-boot
Dear Stefano Babic,
In message <4EC61E4C.8040107@denx.de> 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.
> 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
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_
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-21 21:10 ` Wolfgang Denk
@ 2011-11-22 5:06 ` Simon Glass
2011-11-22 7:18 ` Stefano Babic
2011-11-22 8:59 ` Stefano Babic
1 sibling, 1 reply; 29+ messages in thread
From: Simon Glass @ 2011-11-22 5:06 UTC (permalink / raw)
To: u-boot
Hi Stefano,
On Mon, Nov 21, 2011 at 1:10 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Stefano Babic,
>
> In message <4EC61E4C.8040107@denx.de> 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.
>
>> ? 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
>
> 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
For this conflict I am sending a V4 patch to the list. I am not buying
a lotto ticket today.
Regards,
Simon
> 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
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-22 5:06 ` Simon Glass
@ 2011-11-22 7:18 ` Stefano Babic
0 siblings, 0 replies; 29+ messages in thread
From: Stefano Babic @ 2011-11-22 7:18 UTC (permalink / raw)
To: u-boot
On 22/11/2011 06:06, Simon Glass wrote:
> Hi Stefano,
>
Hi Simon,
>> CONFLICT (content): Merge conflict in lib/hashtable.c
>
> For this conflict I am sending a V4 patch to the list.
Thanks - I remove in the meantime the two patches that does not apply
anymore (the other one is from Andreas), and I will resubmit the pull
request. I take care of your patch in the next round.
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-21 21:10 ` Wolfgang Denk
2011-11-22 5:06 ` Simon Glass
@ 2011-11-22 8:59 ` Stefano Babic
2011-11-22 22:28 ` Wolfgang Denk
[not found] ` <4ECC9D3F.2080100@compulab.co.il>
1 sibling, 2 replies; 29+ messages in thread
From: Stefano Babic @ 2011-11-22 8:59 UTC (permalink / raw)
To: u-boot
On 21/11/2011 22:10, Wolfgang Denk wrote:
> I forgot this in my initial summary of the idea: yes, please send such
> information to the submitter and the list.
Ok, done.
>
> 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
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-22 8:59 ` Stefano Babic
@ 2011-11-22 22:28 ` Wolfgang Denk
[not found] ` <4ECC9D3F.2080100@compulab.co.il>
1 sibling, 0 replies; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-22 22:28 UTC (permalink / raw)
To: u-boot
Dear Stefano Babic,
In message <4ECB6461.8070509@denx.de> you wrote:
> On 21/11/2011 22:10, Wolfgang Denk wrote:
> > I forgot this in my initial summary of the idea: yes, please send such
> > information to the submitter and the list.
>
> Ok, done.
>
> >
> > 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
Applied, thanks.
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
Nothing ever becomes real till it is experienced -- even a proverb is
no proverb to you till your life has illustrated it. - John Keats
^ permalink raw reply [flat|nested] 29+ messages in thread[parent not found: <4ECC9D3F.2080100@compulab.co.il>]
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
[not found] ` <4ECC9D3F.2080100@compulab.co.il>
@ 2011-11-23 8:16 ` Stefano Babic
2011-11-23 9:09 ` Igor Grinberg
0 siblings, 1 reply; 29+ messages in thread
From: Stefano Babic @ 2011-11-23 8:16 UTC (permalink / raw)
To: u-boot
On 23/11/2011 08:14, Igor Grinberg wrote:
> Hi Stefano,
>
Hi Igor,
> 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.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 8:16 ` Stefano Babic
@ 2011-11-23 9:09 ` Igor Grinberg
2011-11-23 16:01 ` Wolfgang Denk
0 siblings, 1 reply; 29+ messages in thread
From: Igor Grinberg @ 2011-11-23 9:09 UTC (permalink / raw)
To: u-boot
On 11/23/11 10:16, Stefano Babic wrote:
> On 23/11/2011 08:14, Igor Grinberg wrote:
>> Hi Stefano,
>>
>
> Hi Igor,
>
>> 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.
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.
So is it different in U-Boot? Interesting...
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 9:09 ` Igor Grinberg
@ 2011-11-23 16:01 ` Wolfgang Denk
2011-11-23 16:26 ` Igor Grinberg
0 siblings, 1 reply; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-23 16:01 UTC (permalink / raw)
To: u-boot
Dear Igor Grinberg,
In message <4ECCB840.9050700@compulab.co.il> you wrote:
>
> > 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.
> 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 <random@developer.example.org>
(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...
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
It usually takes more than three weeks to prepare a good impromptu
speech. - Mark Twain
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 16:01 ` Wolfgang Denk
@ 2011-11-23 16:26 ` Igor Grinberg
2011-11-23 16:57 ` Stefano Babic
0 siblings, 1 reply; 29+ messages in thread
From: Igor Grinberg @ 2011-11-23 16:26 UTC (permalink / raw)
To: u-boot
Hi Wolfgang, Stefano,
On 11/23/11 18:01, Wolfgang Denk wrote:
> Dear Igor Grinberg,
>
> In message <4ECCB840.9050700@compulab.co.il> you wrote:
>>
>>> 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.
>
>> 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 <random@developer.example.org>
>
> (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.
>
>
> 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.
This is perfectly fine. Should we have this written somewhere?
Or should we adopt the Linux version of SubmittingPatches in regard
to signing commits?
>
> 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.
Right, and that is not done also in Linux - when Linus Torvalds pulls
stuff in, he *does not* sign it as well, because (c) *does not* apply
in this case, so you will _not_ have a problem.
>
>
> But maybe I'm just misinterpreting...
Well, if (c) really does not apply here, then probably you are
misinterpreting...
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 16:26 ` Igor Grinberg
@ 2011-11-23 16:57 ` Stefano Babic
2011-11-23 17:08 ` Andy Fleming
2011-11-23 20:12 ` Wolfgang Denk
0 siblings, 2 replies; 29+ messages in thread
From: Stefano Babic @ 2011-11-23 16:57 UTC (permalink / raw)
To: u-boot
On 23/11/2011 17:26, Igor Grinberg wrote:
> 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.
>> 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 <random@developer.example.org>
>>
>> (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...
Stefano
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 16:57 ` Stefano Babic
@ 2011-11-23 17:08 ` Andy Fleming
2011-11-23 20:14 ` Wolfgang Denk
2011-11-23 20:12 ` Wolfgang Denk
1 sibling, 1 reply; 29+ messages in thread
From: Andy Fleming @ 2011-11-23 17:08 UTC (permalink / raw)
To: u-boot
On Wed, Nov 23, 2011 at 10:57 AM, Stefano Babic <sbabic@denx.de> wrote:
> On 23/11/2011 17:26, Igor Grinberg wrote:
>> 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.
>
>>> 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 <random@developer.example.org>
>>>
>>> (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...
I've been not signing off on applied mmc patches, but now that I read
the document carefully, I agree with Igor's interpretation. If you
look under section 13:
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.
Of course, the meaning is established on a per-project basis. And
Wolfgang is right that the same interpretation could be used to claim
that Albert should add his signed-off-by to every patch merged from
the various ARM-sub-repositories. So I think we just need to establish
what the policy is for U-Boot, and everyone can follow it from now-on.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 17:08 ` Andy Fleming
@ 2011-11-23 20:14 ` Wolfgang Denk
2011-11-24 6:57 ` Igor Grinberg
0 siblings, 1 reply; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-23 20:14 UTC (permalink / raw)
To: u-boot
Dear Andy Fleming,
In message <CAKWjMd5N1ozpR2O4rWCzPpPzjbZL1xAT0sRhoDz61aSzZSXEyw@mail.gmail.com> you wrote:
>
> 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.
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.
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
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
- Peter Curran in <DCqM4z.BxB@isgtec.com>
^ permalink raw reply [flat|nested] 29+ messages in thread* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 20:14 ` Wolfgang Denk
@ 2011-11-24 6:57 ` Igor Grinberg
2011-11-24 11:51 ` Wolfgang Denk
0 siblings, 1 reply; 29+ messages in thread
From: Igor Grinberg @ 2011-11-24 6:57 UTC (permalink / raw)
To: u-boot
Hi,
On 11/23/11 22:14, Wolfgang Denk wrote:
> Dear Andy Fleming,
>
> In message <CAKWjMd5N1ozpR2O4rWCzPpPzjbZL1xAT0sRhoDz61aSzZSXEyw@mail.gmail.com> you wrote:
>>
>> 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.
>
> 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.
Is the single patch should be picked manually, from the PatchWork?
If it is, then this is work that custodian does.
Can a custodian pick a patch from the mailing list
(say if PatchWork is down or whatever)?
If yes, then this is also the work that custodian does.
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.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 6:57 ` Igor Grinberg
@ 2011-11-24 11:51 ` Wolfgang Denk
2011-11-24 12:15 ` Igor Grinberg
0 siblings, 1 reply; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-24 11:51 UTC (permalink / raw)
To: u-boot
Dear Igor Grinberg,
In message <4ECDEAE4.5030100@compulab.co.il> you wrote:
>
> 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.
> 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.
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
How many QA engineers does it take to screw in a lightbulb? 3: 1 to
screw it in and 2 to say "I told you so" when it doesn't work.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 11:51 ` Wolfgang Denk
@ 2011-11-24 12:15 ` Igor Grinberg
0 siblings, 0 replies; 29+ messages in thread
From: Igor Grinberg @ 2011-11-24 12:15 UTC (permalink / raw)
To: u-boot
On 11/24/11 13:51, Wolfgang Denk wrote:
> Dear Igor Grinberg,
>
> In message <4ECDEAE4.5030100@compulab.co.il> you wrote:
>>
>> 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.
That's why in Linux rebasing branches that are intended for pulling
is discouraged. Also, for that meter, some maintainers predefine
and guarantee that some of their branches will never be rebased
(e.g. Russell King - stable branches [1])
>
>> 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.
I think both variants do.
[1] http://www.arm.linux.org.uk/developer/git-arm.php
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 16:57 ` Stefano Babic
2011-11-23 17:08 ` Andy Fleming
@ 2011-11-23 20:12 ` Wolfgang Denk
2011-11-24 6:48 ` Igor Grinberg
1 sibling, 1 reply; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-23 20:12 UTC (permalink / raw)
To: u-boot
Dear Stefano Babic,
In message <4ECD25EA.1020508@denx.de> you wrote:
>
> >> | (c) The contribution was provided directly to me by some other
> >> | person who certified (a), (b) or (c) and I have not modified
> >> | it.
...
> >> (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...
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?
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
: I've tried (in vi) "g/[a-z]\n[a-z]/s//_/"...but that doesn't
: cut it. Any ideas? (I take it that it may be a two-pass sort of solution).
In the first pass, install perl. :-) Larry Wall <6849@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-23 20:12 ` Wolfgang Denk
@ 2011-11-24 6:48 ` Igor Grinberg
2011-11-24 7:02 ` Graeme Russ
2011-11-24 11:46 ` Wolfgang Denk
0 siblings, 2 replies; 29+ messages in thread
From: Igor Grinberg @ 2011-11-24 6:48 UTC (permalink / raw)
To: u-boot
On 11/23/11 22:12, Wolfgang Denk wrote:
> Dear Stefano Babic,
>
> In message <4ECD25EA.1020508@denx.de> you wrote:
>>
>>>> | (c) The contribution was provided directly to me by some other
>>>> | person who certified (a), (b) or (c) and I have not modified
>>>> | it.
> ...
>>>> (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...
>
> 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.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 6:48 ` Igor Grinberg
@ 2011-11-24 7:02 ` Graeme Russ
2011-11-24 7:24 ` Igor Grinberg
2011-11-24 11:53 ` Wolfgang Denk
2011-11-24 11:46 ` Wolfgang Denk
1 sibling, 2 replies; 29+ messages in thread
From: Graeme Russ @ 2011-11-24 7:02 UTC (permalink / raw)
To: u-boot
On Nov 24, 2011 5:48 PM, "Igor Grinberg" <grinberg@compulab.co.il> wrote:
>
> On 11/23/11 22:12, Wolfgang Denk wrote:
> > Dear Stefano Babic,
> >
> > In message <4ECD25EA.1020508@denx.de> you wrote:
> >>
> >>>> | (c) The contribution was provided directly to me by some
other
> >>>> | person who certified (a), (b) or (c) and I have not
modified
> >>>> | it.
> > ...
> >>>> (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...
> >
> > 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.
>
Isn't the committer field enough?
And what difference does it really make anyway?
Regards,
Graeme
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 7:02 ` Graeme Russ
@ 2011-11-24 7:24 ` Igor Grinberg
2011-11-24 11:53 ` Wolfgang Denk
1 sibling, 0 replies; 29+ messages in thread
From: Igor Grinberg @ 2011-11-24 7:24 UTC (permalink / raw)
To: u-boot
Hi Graeme,
On 11/24/11 09:02, Graeme Russ wrote:
>
> On Nov 24, 2011 5:48 PM, "Igor Grinberg" <grinberg at compulab.co.il <mailto:grinberg@compulab.co.il>> wrote:
>>
>> On 11/23/11 22:12, Wolfgang Denk wrote:
>> > Dear Stefano Babic,
>> >
>> > In message <4ECD25EA.1020508 at denx.de <mailto:4ECD25EA.1020508@denx.de>> you wrote:
>> >>
>> >>>> | (c) The contribution was provided directly to me by some other
>> >>>> | person who certified (a), (b) or (c) and I have not modified
>> >>>> | it.
>> > ...
>> >>>> (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...
>> >
>> > 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.
>>
>
> Isn't the committer field enough?
Sometimes, it can be useful to see a part of the delivery path,
but as I've said in my other reply in this thread, it is a meter
of choice.
>
> And what difference does it really make anyway?
No functional difference... that's for sure.
It is more like how we want things to be done.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 7:02 ` Graeme Russ
2011-11-24 7:24 ` Igor Grinberg
@ 2011-11-24 11:53 ` Wolfgang Denk
1 sibling, 0 replies; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-24 11:53 UTC (permalink / raw)
To: u-boot
Dear Graeme,
In message <CALButCLDGEiC9vVnnXg0vC60SU=wizQtCX_pGPYfkLoPEYkKLQ@mail.gmail.com> you wrote:
>
> > 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?
d'accord
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
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil Armstrong
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 6:48 ` Igor Grinberg
2011-11-24 7:02 ` Graeme Russ
@ 2011-11-24 11:46 ` Wolfgang Denk
2011-11-24 12:33 ` Igor Grinberg
1 sibling, 1 reply; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-24 11:46 UTC (permalink / raw)
To: u-boot
Dear Igor Grinberg,
In message <4ECDE8C3.2050508@compulab.co.il> you wrote:
>
> > 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 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?
> 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.
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
Experience is what causes a person to make new mistakes instead of
old ones.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 11:46 ` Wolfgang Denk
@ 2011-11-24 12:33 ` Igor Grinberg
2011-11-28 18:52 ` Wolfgang Denk
0 siblings, 1 reply; 29+ messages in thread
From: Igor Grinberg @ 2011-11-24 12:33 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On 11/24/11 13:46, Wolfgang Denk wrote:
> Dear Igor Grinberg,
>
> In message <4ECDE8C3.2050508@compulab.co.il> you wrote:
>>
>>> 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 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.
>
>> 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?
Cherry picking changes the commit id even if there are no conflicts
and can be done only on one commit at a time.
Pulling does not change the commit id, unless there are conflicts.
Rebasing does not change the history of the rebased branch,
unless there are conflicts and it is discouraged among Linux
maintainers on branches intended for pulling.
>
> Sorry, but all this makes not much sense to me. No matter how you
> handle it, it seems a pretty arbitrary decision to me.
Probably, it is arbitrary.
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.
>
> And in all these cases the code is not touched any more.
I think this is not just about the code, but the patch(es)
(including the commit message and id) as the whole and
the maintainer (custodian) work.
Again, no rule - is kind of rule, but it would be nice to have
a document describing this decision, so less questions will arise.
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-24 12:33 ` Igor Grinberg
@ 2011-11-28 18:52 ` Wolfgang Denk
2011-11-29 7:34 ` Igor Grinberg
0 siblings, 1 reply; 29+ messages in thread
From: Wolfgang Denk @ 2011-11-28 18:52 UTC (permalink / raw)
To: u-boot
Dear Igor Grinberg,
In message <4ECE39A9.4080201@compulab.co.il> you wrote:
>
> >> 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.
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 ?
> > 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.
> 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.
> 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.]
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
Always try to do things in chronological order; it's less confusing
that way.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [U-Boot] [GIT PULL] Pull request: u-boot-staging
2011-11-28 18:52 ` Wolfgang Denk
@ 2011-11-29 7:34 ` Igor Grinberg
0 siblings, 0 replies; 29+ messages in thread
From: Igor Grinberg @ 2011-11-29 7:34 UTC (permalink / raw)
To: u-boot
Hi Wolfgang,
On 11/28/11 20:52, Wolfgang Denk wrote:
> Dear Igor Grinberg,
>
> In message <4ECE39A9.4080201@compulab.co.il> you wrote:
>>
>>>> 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.
>
> 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 ?
No, custodian should not sign it this way, because the patch has been
applied already and does not change (neither code, nor the meta data -
commit id and description) by the git pull command.
>
>>> 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.
I understand your point here.
I see it a bit different though, signing is a part of "meta data"
of the commit as much as the commit id is, so AFAIK, the commit id
is the only unique identifier that should be and if you add the
signing information then the id must change.
That is also the reason, you don't have '-s' flag for git pull.
>
>> 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.
That is correct.
I've found the below link [1] with some correspondence involving Linus
about this stuff, but I don't think is really sheds any light on
the problem.
>
>> 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.]
Either me...
We could probably ask for some clarification on the
linux-kernel at vger.kernel.org to understand better the Linux model,
or can define something U-Boot specific.
[1] http://kerneltrap.org/node/3929
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-12-10 21:43 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-09 13:50 [U-Boot] [GIT PULL] Pull request u-boot-staging Stefano Babic
2011-12-10 21:43 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2011-11-23 7:37 [U-Boot] [GIT PULL] Pull request: u-boot-staging Heiko Schocher
2011-11-23 20:26 ` Wolfgang Denk
2011-11-18 8:58 Stefano Babic
2011-11-21 21:10 ` Wolfgang Denk
2011-11-22 5:06 ` Simon Glass
2011-11-22 7:18 ` Stefano Babic
2011-11-22 8:59 ` Stefano Babic
2011-11-22 22:28 ` Wolfgang Denk
[not found] ` <4ECC9D3F.2080100@compulab.co.il>
2011-11-23 8:16 ` Stefano Babic
2011-11-23 9:09 ` Igor Grinberg
2011-11-23 16:01 ` Wolfgang Denk
2011-11-23 16:26 ` Igor Grinberg
2011-11-23 16:57 ` Stefano Babic
2011-11-23 17:08 ` Andy Fleming
2011-11-23 20:14 ` Wolfgang Denk
2011-11-24 6:57 ` Igor Grinberg
2011-11-24 11:51 ` Wolfgang Denk
2011-11-24 12:15 ` Igor Grinberg
2011-11-23 20:12 ` Wolfgang Denk
2011-11-24 6:48 ` Igor Grinberg
2011-11-24 7:02 ` Graeme Russ
2011-11-24 7:24 ` Igor Grinberg
2011-11-24 11:53 ` Wolfgang Denk
2011-11-24 11:46 ` Wolfgang Denk
2011-11-24 12:33 ` Igor Grinberg
2011-11-28 18:52 ` Wolfgang Denk
2011-11-29 7:34 ` Igor Grinberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox