[U-Boot] [STATUS] v2012.04 released, Merge Window is OPEN
Hello all,
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The Merge Window for the next release (v2012.07) is open until Sat May 12, 2012, 23:59:59 CEST = 21 days remaining.
Release "v2012.07" is scheduled in 86 days — on July 16, 2012.
A little statistics [1] - changes since release v2011.12:
Processed 773 csets from 126 developers 19 employers found A total of 132602 lines added, 56539 removed (delta 76063)
Developers with the most changesets Simon Glass 106 (13.7%) Marek Vasut 69 (8.9%) Fabio Estevam 38 (4.9%) Stefano Babic 28 (3.6%) Tom Rini 20 (2.6%) Mike Frysinger 20 (2.6%) Eric Nelson 18 (2.3%) Graeme Russ 17 (2.2%) Christian Riesch 16 (2.1%) Stefan Kristiansson 13 (1.7%) ...
Developers with the most changed lines Marek Vasut 84959 (61.1%) Simon Glass 7677 (5.5%) Stefan Kristiansson 4042 (2.9%) Chander Kashyap 2946 (2.1%) Christian Hitz 2867 (2.1%) Tom Rini 2109 (1.5%) Stefano Babic 2059 (1.5%) Stephan Linz 1972 (1.4%) HeungJun, Kim 1564 (1.1%) Gabe Black 1525 (1.1%) ...
Developers with the most lines removed Tom Rini 1564 (2.8%) David Müller (ELSOFT AG) 660 (1.2%) Sven Schnelle 502 (0.9%) Sughosh Ganu 213 (0.4%) prabhakar.csengg@gmail.com 169 (0.3%) Holger Brunck 113 (0.2%) amartin@nvidia.com 49 (0.1%) Joel Fernandes 48 (0.1%) Andreas Bießmann 34 (0.1%) Igor Grinberg 29 (0.1%) ...
Developers with the most signoffs (total 233) Tom Warren 66 (28.3%) Mike Frysinger 15 (6.4%) Minkyu Kang 14 (6.0%) Kyungmin Park 13 (5.6%) Scott Wood 13 (5.6%) Tom Rini 12 (5.2%) Kumar Gala 12 (5.2%) Amit Virdi 12 (5.2%) Kim Phillips 9 (3.9%) Stefan Roese 8 (3.4%) ...
Developers with the most reviews (total 0)
Developers with the most test credits (total 58) Jason Liu 9 (15.5%) Stefano Babic 8 (13.8%) Marek Vasut 8 (13.8%) Heiko Schocher 6 (10.3%) Simon Glass 5 (8.6%) Fabio Estevam 5 (8.6%) Dirk Behme 2 (3.4%) Tom Rini 1 (1.7%) Holger Brunck 1 (1.7%) Their Name 1 (1.7%) ...
Developers who gave the most tested-by credits (total 58) Eric Nelson 6 (10.3%) Thierry Reding 6 (10.3%) Tom Rini 5 (8.6%) Govindraj.R 5 (8.6%) Marek Vasut 3 (5.2%) Fabio Estevam 3 (5.2%) Christian Riesch 3 (5.2%) Matthias Fuchs 3 (5.2%) Robert Delien 3 (5.2%) Stefano Babic 2 (3.4%) ...
Developers with the most report credits (total 10) Michal Simek 3 (30.0%) Wolfgang Denk 2 (20.0%) Marek Vasut 1 (10.0%) Sughosh Ganu 1 (10.0%) Mike Frysinger 1 (10.0%) Otavio Salvador 1 (10.0%) Jim Lentz 1 (10.0%)
Developers who gave the most report credits (total 10) Stephan Linz 3 (30.0%) Linus Walleij 2 (20.0%) Fabio Estevam 1 (10.0%) Christian Riesch 1 (10.0%) Nobuhiro Iwamatsu 1 (10.0%) Jason Hobbs 1 (10.0%) Ira Snyder 1 (10.0%)
Top changeset contributors by employer (Unknown) 475 (61.4%) DENX Software Engineering 96 (12.4%) Texas Instruments 47 (6.1%) Boundary Devices 26 (3.4%) Freescale 22 (2.8%) Samsung 15 (1.9%) ST Microelectronics 15 (1.9%) Renesas Technology 12 (1.6%) CompuLab 10 (1.3%) Wind River 10 (1.3%) ...
Top lines changed by employer (Unknown) 123233 (88.6%) Texas Instruments 4462 (3.2%) DENX Software Engineering 4332 (3.1%) Samsung 1897 (1.4%) EmCraft Systems 1102 (0.8%) NVidia 1016 (0.7%) Boundary Devices 756 (0.5%) Freescale 575 (0.4%) Wind River 385 (0.3%) ST Microelectronics 334 (0.2%) ...
Employers with the most signoffs (total 233) NVidia 66 (28.3%) (Unknown) 54 (23.2%) Samsung 28 (12.0%) Freescale 24 (10.3%) DENX Software Engineering 22 (9.4%) Texas Instruments 16 (6.9%) ST Microelectronics 12 (5.2%) CompuLab 6 (2.6%) Bosch 2 (0.9%) Boundary Devices 1 (0.4%) ...
Employers with the most hackers (total 131) (Unknown) 78 (59.5%) Texas Instruments 10 (7.6%) DENX Software Engineering 7 (5.3%) Freescale 5 (3.8%) ST Microelectronics 5 (3.8%) NVidia 4 (3.1%) Samsung 4 (3.1%) ESD Electronics 3 (2.3%) Renesas Technology 3 (2.3%) CompuLab 2 (1.5%) ...
[1] See http://www.denx.de/wiki/U-Boot/UbootStat_2012_04 for full statistics, and http://www.denx.de/wiki/UBoot/ReleaseCycle for links to statistics for earlier releases.
Thanks to anybody who contributed to this project!
Best regards,
Wolfgang Denk
U-Boot v2012.04
Marvell>> setenv ipaddr '192.168.1.130' Marvell>> setenv ifhostisup 'ping 192.168.1.100' Marvell>> setenv saywearehappy 'echo "We are happy!"' Marvell>> run ifhostisup saywearehappy; Using egiga0 device ping failed; host 192.168.1.100 is not alive "We are happy!" Marvell>>
This is not the same behaviour as my (unfortunately customised) version based on the ancient U-Boot 2009.11 Other commands are also effected, for example 'ide dev 0' would abort a 'run' command if the device did not exist.
Is this my problem (corrupted source\compilation) or a change in policy ?
Dear Gray, Jason, Heiko, Simon,
I added you, Jason, Heiko and Simon, into the CC-list because there is your commits in the history which seems somewhere to change the behaviour below:
On 22.04.2012 00:55, Gray Remlin wrote:
U-Boot v2012.04
Marvell>> setenv ipaddr '192.168.1.130' Marvell>> setenv ifhostisup 'ping 192.168.1.100' Marvell>> setenv saywearehappy 'echo "We are happy!"' Marvell>> run ifhostisup saywearehappy; Using egiga0 device ping failed; host 192.168.1.100 is not alive "We are happy!" Marvell>>
This is not the same behaviour as my (unfortunately customised) version based on the ancient U-Boot 2009.11 Other commands are also effected, for example 'ide dev 0' would abort a 'run' command if the device did not exist.
Is this my problem (corrupted source\compilation) or a change in policy ?
I took a quick glance over command/main.c. I think this is the "original behaviour" (tree 9c506e 23 Aug 2011):
1374 /* OK - call function to do the command */ 1375 if ((cmdtp->cmd) (cmdtp, flag, argc, argv) != 0) { 1376 rc = -1; 1377 }
run_command returns -1 on failure and
1407 if (run_command (arg, flag) == -1) 1408 return 1;
do_run exits the loop based on that.
Now (tree 762494 6 Mar 2012) builtin_run_command:
1341 rc = cmd_process(flag, argc, argv, &repeatable);
returns the exit code of the command but:
1366 if (builtin_run_command(cmd, flag) == -1) 1367 return 1;
run_command now depends on it to return -1 on failure. If I followed the code right, this is clear change in the behaviour. I hope it is not intentional and can be fixed because I have (too?) scripts that depends on old behaviour. For example:
run get_update_from_usb erase_flash_and_write_it
Sequence must not continue to touching flash if load from USB fails.
--
Timo
Hi again,
On 23.04.2012 08:43, Timo Ketola wrote: ...
I took a quick glance over command/main.c....
common/main.c, of course
1341 rc = cmd_process(flag, argc, argv, &repeatable);
This might fix it:
- rc = cmd_process(flag, argc, argv, &repeatable); + if (cmd_process(flag, argc, argv, &repeatable)) + rc = -1;
--
Timo
Dear Timo,
In message 4F9506AA.4000604@exertus.fi you wrote:
Hi again,
On 23.04.2012 08:43, Timo Ketola wrote: ...
I took a quick glance over command/main.c....
common/main.c, of course
1341 rc = cmd_process(flag, argc, argv, &repeatable);
This might fix it:
rc = cmd_process(flag, argc, argv, &repeatable);
if (cmd_process(flag, argc, argv, &repeatable))rc = -1;
I confirm this fixes the issue. Tested on TQM5200S.
Can you please send a proper patch with SoB line etc. ?
Simon, can you then please send a formal ACK to that patch?
Thanks in advance.
Best regards,
Wolfgang Denk
If one command fails, 'run' command should terminate and not execute any remaining variables.
Signed-off-by: Timo Ketola timo@exertus.fi ---
This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble.
common/main.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c index db181d3..3b9e39a 100644 --- a/common/main.c +++ b/common/main.c @@ -1338,7 +1338,8 @@ static int builtin_run_command(const char *cmd, int flag) continue; }
- rc = cmd_process(flag, argc, argv, &repeatable); + if (cmd_process(flag, argc, argv, &repeatable)) + rc = -1;
/* Did the user stop this? */ if (had_ctrlc ())
Dear "Timo Ketola",
In message 1335175047-30984-1-git-send-email-timo@exertus.fi you wrote:
If one command fails, 'run' command should terminate and not execute any remaining variables.
Signed-off-by: Timo Ketola timo@exertus.fi
This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble.
common/main.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
Tested on TQM5200S.
Tested-by: Wolfgang Denk wd@denx.de
Best regards,
Wolfgang Denk
Hi Timo,
On Mon, Apr 23, 2012 at 9:57 PM, Timo Ketola timo@exertus.fi wrote:
If one command fails, 'run' command should terminate and not execute any remaining variables.
Signed-off-by: Timo Ketola timo@exertus.fi
Tested on sandbox after a bit of investigation.
Tested-by: Simon Glass sjg@chromium.org Acked-by: Simon Glass sjg@chromium.org
This is a clear bug, since cmd_process() returns 1 on failure, but we need builtin_run_command() to return -1. I suspect this might be the problem that Wolfgang found some months ago, although perhaps in a more subtle form.
We really need some tests for this sort of thing - I did create a few for the new run_command_list(), but will make time to add some tests for standard run_command() also.
Thanks for finding and fixing this.
Regards, Simon
This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble.
common/main.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c index db181d3..3b9e39a 100644 --- a/common/main.c +++ b/common/main.c @@ -1338,7 +1338,8 @@ static int builtin_run_command(const char *cmd, int flag) continue; }
- rc = cmd_process(flag, argc, argv, &repeatable);
- if (cmd_process(flag, argc, argv, &repeatable))
- rc = -1;
/* Did the user stop this? */ if (had_ctrlc ()) -- 1.7.5.4
Dear "Timo Ketola",
In message 1335175047-30984-1-git-send-email-timo@exertus.fi you wrote:
If one command fails, 'run' command should terminate and not execute any remaining variables.
Signed-off-by: Timo Ketola timo@exertus.fi
This is based on u-boot-imx.git next. I hope that doesn't cause too much trouble.
common/main.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Hi Timo,
On Apr 23, 2012 5:43 PM, "Timo Ketola" timo@exertus.fi wrote:
Dear Gray, Jason, Heiko, Simon,
I added you, Jason, Heiko and Simon, into the CC-list because there is your commits in the history which seems somewhere to change the behaviour below:
On 22.04.2012 00:55, Gray Remlin wrote:
U-Boot v2012.04
Marvell>> setenv ipaddr '192.168.1.130' Marvell>> setenv ifhostisup 'ping 192.168.1.100' Marvell>> setenv saywearehappy 'echo "We are happy!"' Marvell>> run ifhostisup saywearehappy; Using egiga0 device ping failed; host 192.168.1.100 is not alive "We are happy!" Marvell>>
This is not the same behaviour as my (unfortunately customised) version
based on the ancient U-Boot 2009.11
Other commands are also effected, for example 'ide dev 0' would abort a
'run' command if the device did not exist.
Is this my problem (corrupted source\compilation) or a change in policy
?
I took a quick glance over command/main.c. I think this is the "original behaviour" (tree 9c506e 23 Aug 2011):
1374 /* OK - call function to do the command */ 1375 if ((cmdtp->cmd) (cmdtp, flag, argc, argv) != 0) { 1376 rc = -1; 1377 }
run_command returns -1 on failure and
1407 if (run_command (arg, flag) == -1) 1408 return 1;
do_run exits the loop based on that.
Now (tree 762494 6 Mar 2012) builtin_run_command:
1341 rc = cmd_process(flag, argc, argv, &repeatable);
returns the exit code of the command but:
1366 if (builtin_run_command(cmd, flag) == -1) 1367 return 1;
run_command now depends on it to return -1 on failure. If I followed the code right, this is clear change in the behaviour. I hope it is not intentional and can be fixed because I have (too?) scripts that depends on old behaviour. For example:
run get_update_from_usb erase_flash_and_write_it
Sequence must not continue to touching flash if load from USB fails.
Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow.
Regards, Simon
--
Timo
Dear Simon,
In message CAPnjgZ2vKx3TP6wMswixeYS1q3XM+6WJOiYXwc23jpfim_02tw@mail.gmail.com you wrote:
Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow.
Could you please try and look into this ASAP?
I consider this a serious bug, and would like to fix it in mainline as soon as possible. I think I will then even issue a v12.04.1 bugfix release.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Mon, Apr 23, 2012 at 11:16 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ2vKx3TP6wMswixeYS1q3XM+6WJOiYXwc23jpfim_02tw@mail.gmail.com you wrote:
Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow.
Could you please try and look into this ASAP?
I consider this a serious bug, and would like to fix it in mainline as soon as possible. I think I will then even issue a v12.04.1 bugfix release.
Sorry for the delay - I am travelling this week. Yes I am looking at it now. It would be nice to add a test.
Regards, Simon
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@denx.de "Virtual" means never knowing where your next byte is coming from.
Hi Wolfgang,
On Mon, Apr 23, 2012 at 11:16 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ2vKx3TP6wMswixeYS1q3XM+6WJOiYXwc23jpfim_02tw@mail.gmail.com you wrote:
Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow.
Could you please try and look into this ASAP?
I consider this a serious bug, and would like to fix it in mainline as soon as possible. I think I will then even issue a v12.04.1 bugfix release.
Yes, I have acked it. If you do a bugfix release, and have a bit of extra time, it would be good to pull in the sandbox fix:
http://patchwork.ozlabs.org/patch/149810/
Sorry for the trouble, I hope to get some tests created for this behaviour.
Regards, Simon
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@denx.de "Virtual" means never knowing where your next byte is coming from.
Dear Gray Remlin,
In message 4F932CEC.30808@gmail.com you wrote:
U-Boot v2012.04
Marvell>> setenv ipaddr '192.168.1.130' Marvell>> setenv ifhostisup 'ping 192.168.1.100' Marvell>> setenv saywearehappy 'echo "We are happy!"' Marvell>> run ifhostisup saywearehappy; Using egiga0 device ping failed; host 192.168.1.100 is not alive "We are happy!" Marvell>>
This is not the same behaviour as my (unfortunately customised) version based on the ancient U-Boot 2009.11 Other commands are also effected, for example 'ide dev 0' would abort a 'run' command if the device did not exist.
Is this my problem (corrupted source\compilation) or a change in policy ?
I cannot confirm a problem with the "run' command; tested with v2012.04 in "sandbox" :
------------------------------------ $ echo 'setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug; reset' | ./u-boot
U-Boot 2012.04 (Apr 23 2012 - 10:07:18)
DRAM: 128 MiB Using default environment
In: serial Out: serial Err: serial =>setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug; reset ## Error: "foo" not defined $ ------------------------------------
i. e. the second command ("echo === BUG ===") does not get run.
Ditto on real hardware (here a MPC5200 based board):
------------------------------------ U-Boot 2012.04 (Apr 23 2012 - 10:16:22)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz ... => setenv ifhostisup 'ping 192.168.99.99' => setenv saywearehappy 'echo "We are happy!"' => run ifhostisup saywearehappy Using FEC device ping failed; host 192.168.99.99 is not alive => ------------------------------------
Which exact version of U-Boot and which board configuration are you testing?
Are you using hush shell, or plain old command interpreter?
[In both my tests the hush shell was used.]
Best regards,
Wolfgang Denk
On 23.04.2012 11:20, Wolfgang Denk wrote:
I cannot confirm a problem with the "run' command; tested with v2012.04 in "sandbox" :
$ echo 'setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug; reset' | ./u-boot
I can confirm it:
EXE4026> setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug ## Error: "foo" not defined === BUG === EXE4026>
With the fix I showed earlier:
EXE4026> setenv fail printenv foo;setenv bug echo === BUG ===;run fail bug ## Error: "foo" not defined EXE4026>
Which exact version of U-Boot and which board configuration are you testing?
This is u-boot-imx.git next with not yet merged board adaptation.
Are you using hush shell, or plain old command interpreter?
Plain old...
--
Timo
Dear Gray,
In message 20120423082005.8497F200261@gemini.denx.de I wrote:
I cannot confirm a problem with the "run' command; tested with
...
[In both my tests the hush shell was used.]
I confirm the problem for the old command line interpreter.
Best regards,
Wolfgang Denk
Le 21/04/2012 22:51, Wolfgang Denk a écrit :
Hello all,
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The Merge Window for the next release (v2012.07) is open until Sat May 12, 2012, 23:59:59 CEST = 21 days remaining.
Release "v2012.07" is scheduled in 86 days — on July 16, 2012.
Hi all,
I have moved all u-boot-arm/next commits to u-boot-arm/master and rebased on current u-boot/master.
Word of warning to other ARM tree custodians: make sure to always use current u-boot-arm/master for any pull request, as I might rebase it onto u-boot/master without notice.
Amicalement,
On 04/21/2012 02:51 PM, Wolfgang Denk wrote:
Hello all,
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The following didn't get merged:
http://lists.denx.de/pipermail/u-boot/2012-April/122781.html
which means nobody can pass a device tree to the "bootm" command on ARM (and I think "bootz" too).
On 23.04.2012 17:45, Stephen Warren wrote:
On 04/21/2012 02:51 PM, Wolfgang Denk wrote:
Hello all,
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The following didn't get merged:
http://lists.denx.de/pipermail/u-boot/2012-April/122781.html
which means nobody can pass a device tree to the "bootm" command on ARM (and I think "bootz" too).
Today, I saw a an issue which looks identical to
http://lists.denx.de/pipermail/u-boot/2012-April/122974.html
I will test this tomorrow.
Sounds like an additional reason for a v12.04.1, then.
Best regards
Dirk
Dear Stephen Warren,
In message 4F957907.4070908@wwwdotorg.org you wrote:
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The following didn't get merged:
http://lists.denx.de/pipermail/u-boot/2012-April/122781.html
which means nobody can pass a device tree to the "bootm" command on ARM (and I think "bootz" too).
Argh.
And why did _nobody_ complain during the -rc cycle?
Best regards,
Wolfgang Denk
On 04/23/2012 02:08 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 4F957907.4070908@wwwdotorg.org you wrote:
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The following didn't get merged:
http://lists.denx.de/pipermail/u-boot/2012-April/122781.html
which means nobody can pass a device tree to the "bootm" command on ARM (and I think "bootz" too).
Argh.
And why did _nobody_ complain during the -rc cycle?
Um, what was: http://lists.denx.de/pipermail/u-boot/2012-April/122339.html
And of course the patch I sent to solve it, admittedly late in the release cycle, but still before it.
Dear Stephen Warren,
In message 4F95B886.6050906@wwwdotorg.org you wrote:
And why did _nobody_ complain during the -rc cycle?
Um, what was: http://lists.denx.de/pipermail/u-boot/2012-April/122339.html
And of course the patch I sent to solve it, admittedly late in the release cycle, but still before it.
I missed your patch. It would have been a good idea to reply to one of the [STATUS] messages for the -rc's and raise your concerns in loud and clear voice.
Best regards,
Wolfgang Denk
On Mon, Apr 23, 2012 at 10:08:35PM +0200, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 4F957907.4070908@wwwdotorg.org you wrote:
U-Boot v2012.04 has been released and is available from the git repository and the FTP server.
The following didn't get merged:
http://lists.denx.de/pipermail/u-boot/2012-April/122781.html
which means nobody can pass a device tree to the "bootm" command on ARM (and I think "bootz" too).
Argh.
And why did _nobody_ complain during the -rc cycle?
To try and say what Stephan said, differently, what do we need to do in the future to make sure complains aren't missed? You were on the to: line for at least part of the thread of patches. Do we need to make sure it's assigned to you in patchwork? Poke you on irc? What? :)
Dear Tom Rini,
In message 20120423202619.GG31450@bill-the-cat you wrote:
And why did _nobody_ complain during the -rc cycle?
To try and say what Stephan said, differently, what do we need to do in the future to make sure complains aren't missed? You were on the to:
Fair question. Many others regularly reply to my [STATUS] messages and point out missing stuff. In these late release stages this is most helpful to me, as I usually don't have the full overview over all the long-running multi-version patch series. Also, I don;t always care about each and every bug or issue, especially if it's not in an area where I am respnsible as custodian.
line for at least part of the thread of patches. Do we need to make sure it's assigned to you in patchwork? Poke you on irc? What? :)
Assigning it helps, but I tend to use PW only occasionally.
E-Mail reply to the STATUS messages should be sufficient.
Poking on IRC is always pretty efficient if nothing else works.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Tue, Apr 24, 2012 at 7:06 AM, Wolfgang Denk wd@denx.de wrote:
Dear Tom Rini,
In message 20120423202619.GG31450@bill-the-cat you wrote:
And why did _nobody_ complain during the -rc cycle?
To try and say what Stephan said, differently, what do we need to do in the future to make sure complains aren't missed? You were on the to:
Fair question. Many others regularly reply to my [STATUS] messages and point out missing stuff. In these late release stages this is most helpful to me, as I usually don't have the full overview over all the long-running multi-version patch series. Also, I don;t always care about each and every bug or issue, especially if it's not in an area where I am respnsible as custodian.
line for at least part of the thread of patches. Do we need to make sure it's assigned to you in patchwork? Poke you on irc? What? :)
Assigning it helps, but I tend to use PW only occasionally.
I wonder if we can get Jeremy (jk@ozlabs.org) to add an 'Urgent' status to patchwork? You could do a simple filter in patchwork then
E-Mail reply to the STATUS messages should be sufficient.
Poking on IRC is always pretty efficient if nothing else works.
Regards,
Graeme
Hello,
U-Boot v2012.04.01 has been released and is available from the git repository and the FTP server.
Please update and use this bug fix release instead of v2012.04. It fixes a nasty bug in the command line processing, which can cause incorrect execution of commands and scripts.
Thanks.
Best regards,
Wolfgang Denk
participants (9)
-
Albert ARIBAUD -
Dirk Behme -
Graeme Russ -
Gray Remlin -
Simon Glass -
Stephen Warren -
Timo Ketola -
Tom Rini -
Wolfgang Denk