Between Jon's CFG->CONFIG changes, Sascha's u2boot effort, and the duplicate file cleanup that I've been hacking on, there are a fair number of invasive changes going in to u-boot.
Also, at OLS this year we talked a bit about formalizing the u-boot release procedure and maybe using a merge window and a stabilization period.
So, my question is this; with all the changes being talked about on the list; what order/schedule should be used for bringing these changes into mainline? I think we should decide which pieces should go in first, and plan to stagger them so there is time to recover from each invasive change. Thoughts? I also think that Jon's CONFIG_ changes should probably be merged first, and as soon as possible.
Cheers, g.
Dear Grant,
in message fa686aa40707031148x4e5508ebgac2268741ee98b2e@mail.gmail.com you wrote:
Between Jon's CFG->CONFIG changes, Sascha's u2boot effort, and the duplicate file cleanup that I've been hacking on, there are a fair number of invasive changes going in to u-boot.
Also, at OLS this year we talked a bit about formalizing the u-boot release procedure and maybe using a merge window and a stabilization period.
So, my question is this; with all the changes being talked about on the list; what order/schedule should be used for bringing these changes into mainline? I think we should decide which pieces should go in first, and plan to stagger them so there is time to recover from each invasive change. Thoughts? I also think that Jon's CONFIG_ changes should probably be merged first, and as soon as possible.
I still have to revocer from the pile of work that stacked up during OLS, but I already managed to merge u-boot-testing today.
My plan is:
1) Create a branch and a custodian repo for U-Boot 2.x (note that I dislike both the names "U-Boot-NG" and "U2Boot"; not to mention legal issues when using branded names like "U2").
2) Come up with a description of design criteria for U-Boot - for both the old and the new one.
3) Officially announce the release cycle thingy.
4) Pull Jon's "cmdcfg" patch series into testing.
5) Pull Grant's relocation patch series into testing.
6) Pull as many "trivial" patches into testing as I manage to do.
...
Best regards,
Wolfgang Denk
So, like, the other day Wolfgang Denk mumbled:
I still have to revocer from the pile of work that stacked up during OLS,
You too? :-)
but I already managed to merge u-boot-testing today.
Hooray! Thanks!
My plan is:
- Create a branch and a custodian repo for U-Boot 2.x (note that I dislike both the names "U-Boot-NG" and "U2Boot"; not to mention legal issues when using branded names like "U2").
Ugh. I totally agree with WD here.
- Officially announce the release cycle thingy.
Hey Grant -- Did _that_ sound official enough to you? :-)
- Pull Jon's "cmdcfg" patch series into testing.
Pleas delay this a few days -- there's more brewing still, and it would be best to get the next round completely, I think.
Thanks, jdl
Dear Jon,
in message E1I5pmG-0007T0-4N@jdl.com you wrote:
I still have to revocer from the pile of work that stacked up during OLS,
You too? :-)
Who? Me? No. Not really ;-)
but I already managed to merge u-boot-testing today.
Hooray! Thanks!
You're welcome....
- Officially announce the release cycle thingy.
Hey Grant -- Did _that_ sound official enough to you? :-)
Not yet. There was no schedule attached with it yet :-)
- Pull Jon's "cmdcfg" patch series into testing.
Pleas delay this a few days -- there's more brewing still, and it would be best to get the next round completely, I think.
Ummm... I was really on the *verge* of doing this right now. But it's your work, so you decide. Does that mean that I should delete these patches from my stack ?
06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 00/19] Introduce initial versions of n 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 01/19] Introduce initial versions of n 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 02/19] common/cmd_[a-f]* : Augment CON 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 03/19] common/cmd_[i-z]* : Augment CON 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 04/19] common/ non-cmd: Augment CONFIG 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 05/19] drivers/: Augment CONFIG_COMMAN 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 06/19] fs/: Augment CONFIG_COMMANDS te 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 07/19] disk/: Augment CONFIG_COMMANDS 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 08/19] net/: Augment CONFIG_COMMANDS t 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 09/19] rtc/: Augment CONFIG_COMMANDS t 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 10/19] lib_ppc/: Augment CONFIG_COMMAN 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 11/19] lib_*/: Augment CONFIG_COMMANDS 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 12/19] cpu/mpc*/ : Augment CONFIG_COMM 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 13/19] cpu/ non-mpc*: Augment CONFIG_C 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 14/19] board/[Ma-i]*: Augment CONFIG_C 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 15/19] board/[k-z]*: Augment CONFIG_CO 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 16/19] tools/ : Augment CONFIG_COMMAND 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 17/19] include/ non-config: Augment CO 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 18/19] README: Rewrite command line co 06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 19/19] configs/ mpc86xx: Rewrite comma
Best regards,
Wolfgang Denk
So, like, the other day Wolfgang Denk mumbled:
- Pull Jon's "cmdcfg" patch series into testing.
=20 Pleas delay this a few days -- there's more brewing still, and it would be best to get the next round completely, I think.
Ummm... I was really on the *verge* of doing this right now. But it's your work, so you decide. Does that mean that I should delete these patches from my stack ?
06/11 Jon Loeliger [U-Boot-Users] [PATCH: cmdcfg: 00/19] Introduce initi= al versions of n
Actually, if you are up for it now, please do so. It would be good, I think. But I am slowly working my way through the rest of the include/configs/*.h files as well. If you are OK with only some of them updated at a time, then we should go for it. I had sort of assumed you'd like to see all of the config files updated at approximately the same time. So, if you are willing to do that step incrementally, go for it!
jdl
Dear Jon,
in message E1I5qQW-0007cq-3i@jdl.com you wrote:
Actually, if you are up for it now, please do so. It would be good, I think.
Me too, so I did it.
But I am slowly working my way through the rest of the include/configs/*.h files as well. If you are OK with only some of them updated at a time, then we should go for it. I had sort of assumed you'd like to see all of the config files updated at approximately the same time. So, if you are willing to do that step incrementally, go for it!
I think doing this incrementally now makes most sense. At least now we have a common base again without a long stack of patches that need to be maintained and adapted to other code changes that may (and did) happen.
Best regards,
Wolfgang Denk
So, like, the other day Wolfgang Denk mumbled:
Actually, if you are up for it now, please do so. It would be good, I =
think.
Me too, so I did it.
Excellent! Thanks.
I think doing this incrementally now makes most sense. At least now we have a common base again without a long stack of patches that need to be maintained and adapted to other code changes that may (and did) happen.
OK. I'll merge and rebase my (next) patches on testing now!
jdl
On Tue, Jul 03, 2007 at 11:04:18PM +0200, Wolfgang Denk wrote:
- Create a branch and a custodian repo for U-Boot 2.x (note that I dislike both the names "U-Boot-NG" and "U2Boot"; not to mention legal issues when using branded names like "U2").
It was never meant as a project name, I'd prefer to see it being U-Boot 2.0.0 in the end.
Robert
In message 20070704082032.GL25364@pengutronix.de you wrote:
On Tue, Jul 03, 2007 at 11:04:18PM +0200, Wolfgang Denk wrote:
- Create a branch and a custodian repo for U-Boot 2.x (note that I dislike both the names "U-Boot-NG" and "U2Boot"; not to mention legal issues when using branded names like "U2").
It was never meant as a project name, I'd prefer to see it being U-Boot 2.0.0 in the end.
Fine. The name of the custodian tree will be u-boot-v2, which goes in the same line.
Best regards,
Wolfgang Denk
Hi Grant,
each invasive change. Thoughts? I also think that Jon's CONFIG_ changes should probably be merged first, and as soon as possible.
Yes, these CFG_ defines are real show blockers. Getting rid of them in all board headers could really simplify the integration of kconfig.
CFG_ defines can be everywhere else in the source, as long as they are non defined or changed by a user.
With all user-configurable defines starting with CONFIG_ we can start with the rest :-)
Regards Carsten
On Wed, 2007-07-04 at 14:11, Carsten Schlote wrote:
Hi Grant,
each invasive change. Thoughts? I also think that Jon's CONFIG_ changes should probably be merged first, and as soon as possible.
Yes, these CFG_ defines are real show blockers. Getting rid of them in all board headers could really simplify the integration of kconfig.
CFG_ defines can be everywhere else in the source, as long as they are non defined or changed by a user.
With all user-configurable defines starting with CONFIG_ we can start with the rest :-)
Say.... Not to put _too_ fine a spin on this, but there is a _veeery_ similar issue brewing with the POST CFG_ symbols...
jdl
In message 1183661913.26273.49.camel@ld0161-tx32 you wrote:
Say.... Not to put _too_ fine a spin on this, but there is a _veeery_ similar issue brewing with the POST CFG_ symbols...
Let me know if you have specific ideas how to change these; we're working in that area right now (adding 440EPx POST support), so we can do it better right from the start.
Best regards,
Wolfgang Denk
On Thu, 2007-07-05 at 15:09, Wolfgang Denk wrote:
In message 1183661913.26273.49.camel@ld0161-tx32 you wrote:
Say.... Not to put _too_ fine a spin on this, but there is a _veeery_ similar issue brewing with the POST CFG_ symbols...
Let me know if you have specific ideas how to change these; we're working in that area right now (adding 440EPx POST support), so we can do it better right from the start.
Ah, these have the same problem that the Command Line selection has -- Bit fields are being used at compile time to select code portions. We'll need to introduce symbols such as CONFIG_POST_x for each of the existing CFG_POST_x symbols, and modify the users to have the features conditionally compiled like #if defined(CONFIG_POST_x) as well as modifying some (fewer!) board config files to explicitly list which CONFIG_POST_x features are wanted.
Naturally, this can be done in a round after the Command Line Config updates too!
jdl
Hi,
Am Donnerstag, den 05.07.2007, 13:58 -0500 schrieb Jon Loeliger:
With all user-configurable defines starting with CONFIG_ we can start with the rest :-)
Say.... Not to put _too_ fine a spin on this, but there is a _veeery_ similar issue brewing with the POST CFG_ symbols...
For my kconfig hack in the 1.x tree I to rework both the CONFIG_POST and CONFIG_COMMAND stuff. Can be solved easily.
Carsten
participants (6)
-
Carsten Schlote -
Grant Likely -
Jon Loeliger -
Jon Loeliger -
Robert Schwebel -
Wolfgang Denk