[U-Boot-Users] Please pull u-boot-mpc83xx.git mpc83xx branch
Wolfgang, please do a (and you can cut-n-paste this):
git-pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
[note the mpc83xx branch]
to get the following changes since commit ed4058afc85dc6341fea38cb240beb76296b0d24: Wolfgang Denk (1): Merge with /home/wd/git/u-boot/custodian/u-boot-mpc86xx
Kim Phillips (10): mpc83xx: add MAINTAINER and MAKEALL entries for the mpc8323erdb mpc83xx: fix UEC2->1 typo in libfdt setup code mpc83xx: remaining 8360 libfdt fixes mpc83xx: move common /memory node update mechanism to cpu.c mpc83xx: migrate remaining freescale boards to libfdt mpc83xx: enable libfdt by default on freescale boards mpc83xx: implement board_add_ram_info mpc83xx: suppress unused variable 'val8' warning mpc83xx: move freescale boards to boards/freescale mpc83xx: fix typo in DDR2 programming
Tony Li (1): mpc83xx: Split PIB init code from pci.c and add Qoc3 ATM card support
MAINTAINERS | 30 ++++--- MAKEALL | 1 + Makefile | 10 +- board/freescale/common/pq-mds-pib.c | 102 ++++++++++++++++++++ board/freescale/common/pq-mds-pib.h | 9 ++ board/{ => freescale}/mpc8313erdb/Makefile | 0 board/{ => freescale}/mpc8313erdb/config.mk | 0 board/{ => freescale}/mpc8313erdb/mpc8313erdb.c | 19 +++-- board/{ => freescale}/mpc8313erdb/sdram.c | 3 - board/freescale/mpc8323erdb/mpc8323erdb.c | 37 ++----- board/{ => freescale}/mpc832xemds/Makefile | 2 +- board/{ => freescale}/mpc832xemds/config.mk | 0 board/{ => freescale}/mpc832xemds/mpc832xemds.c | 31 ++++-- board/{ => freescale}/mpc832xemds/pci.c | 64 +++++-------- .../mpc8349emds}/Makefile | 0 board/{ => freescale}/mpc8349emds/config.mk | 0 board/{ => freescale}/mpc8349emds/mpc8349emds.c | 26 ++--- board/{ => freescale}/mpc8349emds/pci.c | 41 ++++++++- board/{ => freescale}/mpc8349itx/Makefile | 0 board/{ => freescale}/mpc8349itx/config.mk | 0 board/{ => freescale}/mpc8349itx/mpc8349itx.c | 21 ++-- board/{ => freescale}/mpc8349itx/pci.c | 39 +++++++- .../mpc8360emds}/Makefile | 2 +- board/{ => freescale}/mpc8360emds/config.mk | 0 board/{ => freescale}/mpc8360emds/mpc8360emds.c | 50 ++++------- board/{ => freescale}/mpc8360emds/pci.c | 48 +-------- board/mpc8349emds/Makefile | 50 ---------- board/mpc8360emds/Makefile | 50 ---------- board/sbc8349/sbc8349.c | 5 +- board/tqm834x/tqm834x.c | 4 +- cpu/mpc83xx/cpu.c | 99 +++++++++++++------ cpu/mpc83xx/pci.c | 15 +++- cpu/mpc83xx/spd_sdram.c | 54 ++++++++--- cpu/mpc83xx/speed.c | 1 + include/common.h | 7 ++ include/configs/MPC8313ERDB.h | 6 +- include/configs/MPC832XEMDS.h | 5 +- include/configs/MPC8349EMDS.h | 2 +- include/configs/MPC8349ITX.h | 2 +- include/configs/MPC8360EMDS.h | 7 +- include/mpc83xx.h | 5 +- 41 files changed, 474 insertions(+), 373 deletions(-) create mode 100644 board/freescale/common/pq-mds-pib.c create mode 100644 board/freescale/common/pq-mds-pib.h rename board/{ => freescale}/mpc8313erdb/Makefile (100%) rename board/{ => freescale}/mpc8313erdb/config.mk (100%) rename board/{ => freescale}/mpc8313erdb/mpc8313erdb.c (94%) rename board/{ => freescale}/mpc8313erdb/sdram.c (99%) copy board/{ => freescale}/mpc832xemds/Makefile (97%) rename board/{ => freescale}/mpc832xemds/config.mk (100%) rename board/{ => freescale}/mpc832xemds/mpc832xemds.c (93%) rename board/{ => freescale}/mpc832xemds/pci.c (89%) copy board/{mpc832xemds => freescale/mpc8349emds}/Makefile (100%) rename board/{ => freescale}/mpc8349emds/config.mk (100%) rename board/{ => freescale}/mpc8349emds/mpc8349emds.c (95%) rename board/{ => freescale}/mpc8349emds/pci.c (91%) rename board/{ => freescale}/mpc8349itx/Makefile (100%) rename board/{ => freescale}/mpc8349itx/config.mk (100%) rename board/{ => freescale}/mpc8349itx/mpc8349itx.c (98%) rename board/{ => freescale}/mpc8349itx/pci.c (90%) rename board/{mpc832xemds => freescale/mpc8360emds}/Makefile (97%) rename board/{ => freescale}/mpc8360emds/config.mk (100%) rename board/{ => freescale}/mpc8360emds/mpc8360emds.c (90%) rename board/{ => freescale}/mpc8360emds/pci.c (88%) delete mode 100644 board/mpc8349emds/Makefile delete mode 100644 board/mpc8360emds/Makefile
Thanks,
Kim
In message 20070817093906.05cca34d.kim.phillips@freescale.com you wrote:
Wolfgang, please do a (and you can cut-n-paste this):
git-pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Done.
[note the mpc83xx branch]
May I please ask that you use branches for other stuff, and allow me to merge from the "trunk"? Thanks.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 20070817093906.05cca34d.kim.phillips@freescale.com you wrote:
Wolfgang, please do a (and you can cut-n-paste this):
git-pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Done.
[note the mpc83xx branch]
May I please ask that you use branches for other stuff, and allow me to merge from the "trunk"? Thanks.
Hi Wolfgang and The List,
In the u-boot-fdt repo, I've been using the "fdt" branch for "ready to merge" patches and have advocated standardizing on a "merge" branch for "ready to merge" patches in the TWiki (as well as a "testing" branch for "merge candidate" patches). http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t
Based on your request above, it would appear that we have not convinced you that pulling from a branch is a Good Thing[tm]. If that is the case, the alternate technique I would advocate would be...
* Maintain the "ready to merge" patches in the master branch (per your request).
* Track the main u-boot repository via a branch "u-boot" (picking a name arbitrarily)
This would still allow the rebasing by doing a periodic pull of the master repo into the "u-boot" branch and then rebasing the "master" on the "u-boot" branch. I have not tried this, but I don't see any reason why it would not work.
The "u-boot" branch would not need to be pushed back to the denx.de repository, so it would cut down the number of published branches by one (generally a 100% reduction ;-). I would still advocate using work-in-progress (e.g. "testing") branch(es) that are pushed back to denx.de as the need arises. I have not felt a need myself, but I can see a place for it for patches that introduce major changes that may take time to mature.
Trivia: ------- One of the reasons I've advocated using a branch to pull from is because linux does it this way, although their methodology and organization of their repositories is somewhat different. They generally create a special branch for Linus to pull from (a quick search on gmane.org shows "for-linus", "release", "merge", "upstream-linus", "upstream",... so there isn't much consistency there to model our methodology after).
An argument for using the "master" branch is that outstanding patches are easier to find and view via gitweb. Figuring out where to click to view a branch is not obvious, it requires scrolling down to the bottom of the page. We've had that issue on the email list and I have to sympathize because it threw me for a minute myself the first time I tried to see changes that were in a branch.
What is the wisdom of the crowd[1]?
Best regards, gvb
Jerry Van Baren wrote:
Wolfgang Denk wrote:
In message 20070817093906.05cca34d.kim.phillips@freescale.com you wrote:
Wolfgang, please do a (and you can cut-n-paste this):
git-pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
Done.
[note the mpc83xx branch]
May I please ask that you use branches for other stuff, and allow me to merge from the "trunk"? Thanks.
Hi Wolfgang and The List,
In the u-boot-fdt repo, I've been using the "fdt" branch for "ready to merge" patches and have advocated standardizing on a "merge" branch for "ready to merge" patches in the TWiki (as well as a "testing" branch for "merge candidate" patches). http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t
Based on your request above, it would appear that we have not convinced you that pulling from a branch is a Good Thing[tm]. If that is the case, the alternate technique I would advocate would be...
- Maintain the "ready to merge" patches in the master branch (per your
request).
- Track the main u-boot repository via a branch "u-boot" (picking a name
arbitrarily)
This would still allow the rebasing by doing a periodic pull of the master repo into the "u-boot" branch and then rebasing the "master" on the "u-boot" branch. I have not tried this, but I don't see any reason why it would not work.
The "u-boot" branch would not need to be pushed back to the denx.de repository, so it would cut down the number of published branches by one (generally a 100% reduction ;-). I would still advocate using work-in-progress (e.g. "testing") branch(es) that are pushed back to denx.de as the need arises. I have not felt a need myself, but I can see a place for it for patches that introduce major changes that may take time to mature.
Trivia:
One of the reasons I've advocated using a branch to pull from is because linux does it this way, although their methodology and organization of their repositories is somewhat different. They generally create a special branch for Linus to pull from (a quick search on gmane.org shows "for-linus", "release", "merge", "upstream-linus", "upstream",... so there isn't much consistency there to model our methodology after).
An argument for using the "master" branch is that outstanding patches are easier to find and view via gitweb. Figuring out where to click to view a branch is not obvious, it requires scrolling down to the bottom of the page. We've had that issue on the email list and I have to sympathize because it threw me for a minute myself the first time I tried to see changes that were in a branch.
What is the wisdom of the crowd[1]?
Best regards, gvb
Sorry for talking to myself, but the Koha project just announced they switched to git and have a very nice writeup on their methodology. A quick read makes me think their methodology and writeup is very close to what we either already are or should be doing. Koha's "QA Repo" and "Release Managers Repo" don't exist in our methodology and the "Liblime", "Paul", etc. repos are our custodian repos.
They do the master repo tracking in the "origin" branch, which is something I should have considered before penning my diatribe (above).
http://wiki.koha.org/doku.php?id=en:development:git_usage
Best regards, gvb
In message 46C984A0.5030602@smiths-aerospace.com you wrote:
Based on your request above, it would appear that we have not convinced you that pulling from a branch is a Good Thing[tm]. If that is the case, the alternate technique I would advocate would be...
Pulling from a branch is OK with me, iff
* I know about it * the branch to pull from remains static, i. e. it doesn't change with every other pull request.
However, I think that what I pull from is considered themost stable, best tested branch, so to me it makes sense if this is the "trunk" where everybody else is pulling from who is interested in a certain tree.
An argument for using the "master" branch is that outstanding patches are easier to find and view via gitweb. Figuring out where to click to view a branch is not obvious, it requires scrolling down to the bottom of the page. We've had that issue on the email list and I have to sympathize because it threw me for a minute myself the first time I tried to see changes that were in a branch.
That's my thinking - if you tell someone "get this from the xxx custodian repo", they will most not be looking for branches.
Best regards,
Wolfgang Denk
participants (3)
-
Jerry Van Baren -
Kim Phillips -
Wolfgang Denk