[U-Boot-Users] Please pull 85xx
This includes current changes in the libfdt testing branch, as they are required for the 85xx changes to work. If we need to rework this a different way, let me know. I'm not afraid of rebasing.
The following changes since commit 41be969f4957115ed7b1fe8b890bfaee99d7a7a2: Wolfgang Denk (1): Release v1.3.1
are found in the git repository at:
git://www.denx.de/git/u-boot-mpc85xx.git
Gerald Van Baren (2): Add spaces around the = in the fdt print format. Conditionally compile fdt_fixup_ethernet()
Haiying Wang (1): Add PCI Express support on MPC8568MDS
Kumar Gala (25): Fix build breakage due to libfdt import Conditionally compile fdt_support.c Add common memory fixup function Added fdt_fixup_stdout that uses aliases to set linux,stdout-path Convert boards that set memory node to use fdt_fixup_memory() Add libfdt based ft_cpu_setup for mpc85xx Update MPC8544DS to use libfdt Update MPC8544 DS config Stop using immap_t for guts offset on 85xx Stop using immap_t for cpm offset on 85xx Update MPC8560 ADS to use libfdt Update MPC8540 ADS to use libfdt Update MPC85xx CDS to use libfdt Update MPC8568 MDS to use libfdt Remove CONFIG_OF_FLAT_TREE related code from mpc85xx since we now use libfdt Stop using immap_t on 85xx Use standard LAWAR_TRGT_IF_* defines for LAW setup on 85xx Move the MPC8568 MDS board under board/freescale. Move the MPC8560 ADS board under board/freescale. Move the MPC8540 ADS board under board/freescale. Move the MPC8541/MPC8555/MPC8548 CDS board under board/freescale. Update Freescale MPC85xx ADS/CDS/MDS board config Handle Asynchronous DDR clock on 85xx Update Freescale MPC85xx ADS/CDS/MDS board config Handle MPC85xx PCIe reset errata (PCI-Ex 38)
Makefile | 12 +- board/cds/mpc8548cds/Makefile | 60 ----- board/cds/mpc8555cds/Makefile | 60 ----- board/cds/mpc8555cds/init.S | 255 ------------------ board/cds/mpc8555cds/u-boot.lds | 150 ----------- board/cm5200/cm5200.c | 15 +- board/{cds => freescale}/common/cadmus.c | 0 board/{cds => freescale}/common/cadmus.h | 0 board/{cds => freescale}/common/eeprom.c | 0 board/{cds => freescale}/common/eeprom.h | 0 board/{cds => freescale}/common/ft_board.c | 50 ++-- board/{cds => freescale}/common/via.c | 0 board/{cds => freescale}/common/via.h | 0 board/{ => freescale}/mpc8540ads/Makefile | 0 board/{ => freescale}/mpc8540ads/config.mk | 0 board/{ => freescale}/mpc8540ads/init.S | 0 board/{ => freescale}/mpc8540ads/mpc8540ads.c | 44 ++-- board/{ => freescale}/mpc8540ads/u-boot.lds | 4 +- board/{cds => freescale}/mpc8541cds/Makefile | 0 board/{cds => freescale}/mpc8541cds/config.mk | 0 board/{cds => freescale}/mpc8541cds/init.S | 0 board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 44 +++- board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +- board/freescale/mpc8544ds/init.S | 25 +-- board/freescale/mpc8544ds/mpc8544ds.c | 81 +++--- .../mpc8541cds => freescale/mpc8548cds}/Makefile | 0 board/{cds => freescale}/mpc8548cds/config.mk | 0 board/{cds => freescale}/mpc8548cds/init.S | 25 +-- board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 58 ++--- board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +- .../mpc8541cds => freescale/mpc8555cds}/Makefile | 0 board/{cds => freescale}/mpc8555cds/config.mk | 0 .../mpc8541cds => freescale/mpc8555cds}/init.S | 0 board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 44 +++- .../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +- .../{mpc8540ads => freescale/mpc8560ads}/Makefile | 0 board/{ => freescale}/mpc8560ads/config.mk | 0 board/{mpc8540ads => freescale/mpc8560ads}/init.S | 0 board/{ => freescale}/mpc8560ads/mpc8560ads.c | 62 ++--- board/{ => freescale}/mpc8560ads/u-boot.lds | 4 +- board/{ => freescale}/mpc8568mds/Makefile | 4 +- board/{ => freescale}/mpc8568mds/bcsr.c | 0 board/{ => freescale}/mpc8568mds/bcsr.h | 0 board/{ => freescale}/mpc8568mds/config.mk | 0 board/{ => freescale}/mpc8568mds/init.S | 10 +- board/{ => freescale}/mpc8568mds/mpc8568mds.c | 182 ++++++++++++- board/{ => freescale}/mpc8568mds/u-boot.lds | 4 +- board/ids8247/ids8247.c | 17 +- board/mpc8540eval/mpc8540eval.c | 14 +- board/mpc8560ads/Makefile | 52 ---- board/mpc8560ads/init.S | 280 -------------------- board/mpc8568mds/ft_board.c | 45 --- board/pm854/pm854.c | 14 +- board/pm856/pm856.c | 11 +- board/sbc8560/sbc8560.c | 14 +- board/stxgp3/stxgp3.c | 6 +- board/stxssa/stxssa.c | 6 +- board/tqm85xx/sdram.c | 6 +- board/tqm85xx/tqm85xx.c | 8 +- common/Makefile | 3 +- common/cmd_fdt.c | 4 +- common/fdt_support.c | 130 +++++++++- cpu/mpc83xx/cpu.c | 18 +-- cpu/mpc85xx/Makefile | 4 +- cpu/mpc85xx/commproc.c | 28 +- cpu/mpc85xx/cpu.c | 124 ++-------- cpu/mpc85xx/cpu_init.c | 16 +- cpu/mpc85xx/ether_fcc.c | 54 ++-- cpu/mpc85xx/fdt.c | 64 +++++ cpu/mpc85xx/interrupts.c | 10 +- cpu/mpc85xx/pci.c | 34 +--- cpu/mpc85xx/qe_io.c | 4 +- cpu/mpc85xx/serial_scc.c | 35 ++-- cpu/mpc85xx/spd_sdram.c | 17 +- cpu/mpc85xx/speed.c | 34 ++- cpu/mpc85xx/traps.c | 4 +- drivers/pci/fsl_pci_init.c | 23 ++ include/asm-ppc/immap_85xx.h | 45 ++-- include/asm-ppc/immap_fsl_pci.h | 4 +- include/asm-ppc/iopin_85xx.h | 40 ++-- include/asm-ppc/mmu.h | 4 +- include/common.h | 1 + include/configs/MPC8540ADS.h | 12 +- include/configs/MPC8541CDS.h | 13 +- include/configs/MPC8544DS.h | 119 ++------- include/configs/MPC8548CDS.h | 103 +------- include/configs/MPC8555CDS.h | 13 +- include/configs/MPC8560ADS.h | 14 +- include/configs/MPC8568MDS.h | 39 ++- include/e500.h | 1 + include/fdt_support.h | 1 + include/ioports.h | 2 +- 92 files changed, 909 insertions(+), 1786 deletions(-) delete mode 100644 board/cds/mpc8548cds/Makefile delete mode 100644 board/cds/mpc8555cds/Makefile delete mode 100644 board/cds/mpc8555cds/init.S delete mode 100644 board/cds/mpc8555cds/u-boot.lds rename board/{cds => freescale}/common/cadmus.c (100%) rename board/{cds => freescale}/common/cadmus.h (100%) rename board/{cds => freescale}/common/eeprom.c (100%) rename board/{cds => freescale}/common/eeprom.h (100%) rename board/{cds => freescale}/common/ft_board.c (70%) rename board/{cds => freescale}/common/via.c (100%) rename board/{cds => freescale}/common/via.h (100%) copy board/{ => freescale}/mpc8540ads/Makefile (100%) rename board/{ => freescale}/mpc8540ads/config.mk (100%) copy board/{ => freescale}/mpc8540ads/init.S (100%) rename board/{ => freescale}/mpc8540ads/mpc8540ads.c (90%) rename board/{ => freescale}/mpc8540ads/u-boot.lds (98%) copy board/{cds => freescale}/mpc8541cds/Makefile (100%) rename board/{cds => freescale}/mpc8541cds/config.mk (100%) copy board/{cds => freescale}/mpc8541cds/init.S (100%) rename board/{cds => freescale}/mpc8541cds/mpc8541cds.c (95%) copy board/{cds => freescale}/mpc8541cds/u-boot.lds (98%) copy board/{cds/mpc8541cds => freescale/mpc8548cds}/Makefile (100%) rename board/{cds => freescale}/mpc8548cds/config.mk (100%) rename board/{cds => freescale}/mpc8548cds/init.S (90%) rename board/{cds => freescale}/mpc8548cds/mpc8548cds.c (92%) rename board/{cds => freescale}/mpc8548cds/u-boot.lds (97%) rename board/{cds/mpc8541cds => freescale/mpc8555cds}/Makefile (100%) rename board/{cds => freescale}/mpc8555cds/config.mk (100%) rename board/{cds/mpc8541cds => freescale/mpc8555cds}/init.S (100%) rename board/{cds => freescale}/mpc8555cds/mpc8555cds.c (95%) rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (98%) rename board/{mpc8540ads => freescale/mpc8560ads}/Makefile (100%) rename board/{ => freescale}/mpc8560ads/config.mk (100%) rename board/{mpc8540ads => freescale/mpc8560ads}/init.S (100%) rename board/{ => freescale}/mpc8560ads/mpc8560ads.c (94%) rename board/{ => freescale}/mpc8560ads/u-boot.lds (98%) rename board/{ => freescale}/mpc8568mds/Makefile (97%) rename board/{ => freescale}/mpc8568mds/bcsr.c (100%) rename board/{ => freescale}/mpc8568mds/bcsr.h (100%) rename board/{ => freescale}/mpc8568mds/config.mk (100%) rename board/{ => freescale}/mpc8568mds/init.S (97%) rename board/{ => freescale}/mpc8568mds/mpc8568mds.c (65%) rename board/{ => freescale}/mpc8568mds/u-boot.lds (98%) delete mode 100644 board/mpc8560ads/Makefile delete mode 100644 board/mpc8560ads/init.S delete mode 100644 board/mpc8568mds/ft_board.c create mode 100644 cpu/mpc85xx/fdt.c
Andy Fleming wrote:
This includes current changes in the libfdt testing branch, as they are required for the 85xx changes to work. If we need to rework this a different way, let me know. I'm not afraid of rebasing.
The following changes since commit 41be969f4957115ed7b1fe8b890bfaee99d7a7a2: Wolfgang Denk (1): Release v1.3.1
are found in the git repository at:
git://www.denx.de/git/u-boot-mpc85xx.git
Gerald Van Baren (2): Add spaces around the = in the fdt print format. Conditionally compile fdt_fixup_ethernet()
Haiying Wang (1): Add PCI Express support on MPC8568MDS
Kumar Gala (25): Fix build breakage due to libfdt import Conditionally compile fdt_support.c :
[snip]
Including the libfdt testing branch is fine by me. Kim and I did a bit of patch swapping in August (same issue, patch interdependencies) and git magically figured it all out (Linus' choice to use a hash to identify patches was very smart).
Thanks, gvb
In message Pine.LNX.4.61.0712112338550.25073@ld0175-tx32.am.freescale.net you wrote:
This includes current changes in the libfdt testing branch, as they are required for the 85xx changes to work. If we need to rework this a different way, let me know. I'm not afraid of rebasing.
I really hate such pull requests that include changes from other repositories like yours is doing.
If you need the libfdt stuff, fine, please use it for your work, but do not include this into the branch you request me to pull from.
Please keep the custodian's repositories separated and allow me to decide what to pull, and when.
The next time I will reject such a pull request.
The following changes since commit 41be969f4957115ed7b1fe8b890bfaee99d7a7a2: Wolfgang Denk (1): Release v1.3.1
are found in the git repository at:
git://www.denx.de/git/u-boot-mpc85xx.git
Merged. Thanks.
Best regards,
Wolfgang Denk
On Thursday 27 December 2007, Wolfgang Denk wrote:
This includes current changes in the libfdt testing branch, as they are required for the 85xx changes to work. If we need to rework this a different way, let me know. I'm not afraid of rebasing.
I really hate such pull requests that include changes from other repositories like yours is doing.
If you need the libfdt stuff, fine, please use it for your work, but do not include this into the branch you request me to pull from.
That can be very hard sometimes. Please note that I had the same problem and also included the libfdt changes from Kumar into the 4xx for-1.3.2 branch, since this brings all this fdt work to a very nice status. Without it, it is nearly impossible to do any decent fdt stuff anymore. And since you didn't pull the changes from Jerry into the master or testing repository at that time, we *had* to do something to have a chance to get the stuff ready for merging within the merge window.
I am aware that you didn't find the time to do this at that time, but we had to act to not miss the merge window with all our changes. So please understand why we did it this way (Andy, please correct me if I don't speak for you here).
Best regards, Stefan
===================================================================== 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@denx.de =====================================================================
In message 200712271701.09072.sr@denx.de you wrote:
That can be very hard sometimes. Please note that I had the same problem and also included the libfdt changes from Kumar into the 4xx for-1.3.2 branch, since this brings all this fdt work to a very nice status. Without it, it is nearly impossible to do any decent fdt stuff anymore. And since you didn't pull the changes from Jerry into the master or testing repository at that time, we *had* to do something to have a chance to get the stuff ready for merging within the merge window.
But when you pull any other repository into your tree, you leave me no option wether I want to accept this repo as iis or request changes or if I want to omit parts of it for one reason or another.
When I'm pulling the libfdt repo, I will check what's in there, but when I pull the 4xx repo, I do NOT want to have to check any other repo in parallel, too.
Sorry, if there are such dependencies, then please drop me a note and we will find a way to dort it out. YOu know that I will try to help if somebody has a reasonable request.
The current situation is not acceptable to me. The custodian reposi- tories are supposed to be strictly orthogonal to each other. If they are not, I will refuse to pull.
Best regards,
Wolfgang Denk
On Thursday 27 December 2007, Wolfgang Denk wrote:
That can be very hard sometimes. Please note that I had the same problem and also included the libfdt changes from Kumar into the 4xx for-1.3.2 branch, since this brings all this fdt work to a very nice status. Without it, it is nearly impossible to do any decent fdt stuff anymore. And since you didn't pull the changes from Jerry into the master or testing repository at that time, we *had* to do something to have a chance to get the stuff ready for merging within the merge window.
But when you pull any other repository into your tree, you leave me no option wether I want to accept this repo as iis or request changes or if I want to omit parts of it for one reason or another.
When I'm pulling the libfdt repo, I will check what's in there, but when I pull the 4xx repo, I do NOT want to have to check any other repo in parallel, too.
If I understand this correctly, then recent git versions are capable of handling such cases without problems. Meaning pulling patches from another repo, that are allready present should cause no problems.
Sorry, if there are such dependencies, then please drop me a note and we will find a way to dort it out. YOu know that I will try to help if somebody has a reasonable request.
I did ask you once or twice about this fdt repo, but I should have have been more insistant.
The current situation is not acceptable to me. The custodian reposi- tories are supposed to be strictly orthogonal to each other. If they are not, I will refuse to pull.
Right. Generally I share this opinion. All this is probably something we have to "learn" in the next few merge windows.
I'll try to remove the already commited fdt patches from my repo and merge with mainline before asking you to pull from the 4xx repo. OK?
Best regards, Stefan
===================================================================== 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@denx.de =====================================================================
In message 200712271922.50572.sr@denx.de you wrote:
When I'm pulling the libfdt repo, I will check what's in there, but when I pull the 4xx repo, I do NOT want to have to check any other repo in parallel, too.
If I understand this correctly, then recent git versions are capable of handling such cases without problems. Meaning pulling patches from another repo, that are allready present should cause no problems.
Yes, *if* they are present, and if they are identical.
If I decide not to pull libfdt yet for some reason (for example, because I rejected partrs of it and now wait for a new version), pulling from your repo will sneak in the code I intended to reject.
If your version and what I pulled (and eventually modified) from libfdt differ, who knows what the end resulkt would look like?
Sorry, if there are such dependencies, then please drop me a note and we will find a way to dort it out. YOu know that I will try to help if somebody has a reasonable request.
I did ask you once or twice about this fdt repo, but I should have have been more insistant.
Sorry, it seems I did not understand the importance of that request. Sorry.
I'll try to remove the already commited fdt patches from my repo and merge with mainline before asking you to pull from the 4xx repo. OK?
Just rebase your stuff against current version and this should resolve easily, I guess.
Here it was easy, as I accepted libfdt as it was, an you probably have the correct code, too. But it could have been worse.
Best regards,
Wolfgang Denk
On Dec 26, 2007 5:38 PM, Wolfgang Denk wd@denx.de wrote:
In message Pine.LNX.4.61.0712112338550.25073@ld0175-tx32.am.freescale.net you wrote:
This includes current changes in the libfdt testing branch, as they are required for the 85xx changes to work. If we need to rework this a different way, let me know. I'm not afraid of rebasing.
I really hate such pull requests that include changes from other repositories like yours is doing.
If you need the libfdt stuff, fine, please use it for your work, but do not include this into the branch you request me to pull from.
Please keep the custodian's repositories separated and allow me to decide what to pull, and when.
I understand, completely. It's a messy problem. I made sure to alert you to this so that you would have the opportunity to hold off on pulling my tree in the event you wanted more time to look at the FDT tree.
However, there's no way I could have applied any of the other patches that were 85xx-specific without those changes--they were dependent. In the future, I can choose to reject or hold off on applying any patches which don't apply to the current custodian repository. But the drawback is that people who are working on the cutting edge will have to self-maintain their patches longer.
My intent in pulling in the fdt changes and Kumar's patches was to have the custodian tree represent the current state-of-the-art of 85xx development, thus allowing Kumar to move ahead, and allowing others to build off what he has done. If you had decided to reject any of the FDT patches, I would have happily (if not cheerfully) rebased my tree, and either fixed up the latest patches on my own, or requested that Kumar resubmit. This seemed to me to be a reasonable way forward: it allows development to continue, while keeping the main u-boot tree free from development work.
Anyway, I'm fine with whatever policy we want to follow. But if this happens again, I'd like to know what to do. :) I can always just create a side tree which has the latest state of development, while I wait for any dependent changes to propagate into the mainline.
Andy
Dear Andy,
in message 2acbd3e40712291349u73982ccdub087eb4d90d88369@mail.gmail.com you wrote:
Please keep the custodian's repositories separated and allow me to decide what to pull, and when.
I understand, completely. It's a messy problem. I made sure to alert you to this so that you would have the opportunity to hold off on pulling my tree in the event you wanted more time to look at the FDT tree.
I understand your situation, too.
Anyway, I'm fine with whatever policy we want to follow. But if this happens again, I'd like to know what to do. :) I can always just create a side tree which has the latest state of development, while I wait for any dependent changes to propagate into the mainline.
Well, let's try this:
If your work depends on patches from another repo, please ask the custodian of this other repo to send a pull request, and ask him to mention in his pull request that this is urgent becasue ... depends on it.
I will try to pull such things into testing ASAP.
Best regards,
Wolfgang Denk
Dear Wolfgang, you wrote:
*snip*
Anyway, I'm fine with whatever policy we want to follow. But if this happens again, I'd like to know what to do. :) I can always just create a side tree which has the latest state of development, while I wait for any dependent changes to propagate into the mainline.
Well, let's try this:
If your work depends on patches from another repo, please ask the custodian of this other repo to send a pull request, and ask him to mention in his pull request that this is urgent becasue ... depends on it.
I guess I'm still a bit confused about the process. So in case of inter-repo dependencies, would you like something like the following?
1. ask the involved custodian(s) to merge my pieces that I depend on, but that belong to different FA, and have them send pull requests to you
2. you merge those onto the testing branch
Should I then rebase against the testing repo, or wait until it makes to the main line and only then come up with my pull request? (as there's a general rule for pull requests to be based on the main line..). Please clarfiy.
kind regards, Rafal
Dear Rafal,
in message 477BD21F.7040205@semihalf.com you wrote:
If your work depends on patches from another repo, please ask the custodian of this other repo to send a pull request, and ask him to mention in his pull request that this is urgent becasue ... depends on it.
I guess I'm still a bit confused about the process. So in case of inter-repo dependencies, would you like something like the following?
I'm still trying to figure out myself how we could come up with a compromize of having clean and orthogonal custodian's repositories on one side and a practical solution that is usable without introducing unnecessary delays on the other side.
Thanks for your patience with me.
- ask the involved custodian(s) to merge my pieces that I depend on, but that
belong to different FA, and have them send pull requests to you
- you merge those onto the testing branch
No.
Assume you depend on feature X from repo xxx and on feature Y from repo yyy.
Then you would ask both the custodians of the xxx and yyy repos to send pull requests. The pull request should contain a note that others (you) depend on this stuff, thus marking it as urgent. [yes, I know, sombody is always depending on some patch, so this is not exactly a sharp definition. But we have to try something, only then we can see if it works or not.]
I would then pull the xxx and yyy repos into testing.
Should I then rebase against the testing repo, or wait until it makes to the main line and only then come up with my pull request? (as there's a general
Yes, you would then base your work on testing. I promise that I will try to keep delays as small as possible.
rule for pull requests to be based on the main line..). Please clarfiy.
Above assumes that the features X and Y are "ripe", i. e. indeed ready for inclusion into main line - but this is necessary in any case, otherwise you could not use them in the first place because if they were not clean for mainline I could never pull in your code which depends on / includes them.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Rafal,
in message 477BD21F.7040205@semihalf.com you wrote:
If your work depends on patches from another repo, please ask the custodian of this other repo to send a pull request, and ask him to mention in his pull request that this is urgent becasue ... depends on it.
I guess I'm still a bit confused about the process. So in case of inter-repo dependencies, would you like something like the following?
I'm still trying to figure out myself how we could come up with a compromize of having clean and orthogonal custodian's repositories on one side and a practical solution that is usable without introducing unnecessary delays on the other side.
Thanks for your patience with me.
As I see it, when we have this situation and need a fast stream into u-boot, we need to (and can) use branches effectively. Using the late lamented situation where 85xx was dependent on fdt changes, ideally Andy and I do some coordinating.
1) I would put *just the patches that Andy needs* into my "master" branch, putting less urgent patches into a side branch (e.g. "testing").
2) Andy can then pull my "master" branch into his repository and add his Value Added[tm] patches on top of the minimum necessary u-boot-fdt patches. [1]
3) Andy and I clamor for Wolfgang to pull u-boot-fdt and then u-boot-85xx.
4-good) If Wolfgang approves of u-boot-fdt, half is well. If Wolfgang approves u-boot-85xx, all is well.
4-bad) In a worst case scenario, Wolfgang requires changes to the u-boot-fdt patches. I (or the responsible party) would reroll the u-boot-fdt patches and generate a new "master" branch with acceptable patches. Andy would have to save his Value Added[tm] patches, do a "git reset --hard" back to the original ToT, re-pull my u-boot-fdt "master" branch, and then re-apply his Value Added[tm] patches (fixing breakages as needed). Goto step 3).
This should be quite reasonable in practice, although it will take some coordination. Even after the fact, we (me in the fdt/85xx example) can use git-rebase or (git reset --hard + re-apply patches) to put only the critical patches in "master" and move the non-critical patches to a side branch, e.g. "testing".
In the specific instance of u-boot-fdt + u-boot-85xx, we ended up in state 4-good) by luck, laziness, some flexibility from Wolfgang. The luck part was the fact that, due to laziness on my part, all or nearly all of the changes in the u-boot-fdt tree were the critical set needed by Andy. Wolfgang was flexible enough to pull my "testing" branch (rather than "master"), then Andy's 85xx patches, approve of both, and life was good.
HTH, gvb
[1] If Andy were paranoid, he would... a) Pull my "master" branch into a new branch in his repository, say "ubootfdt" b) Create a new branch based on "ubootfdt", say "testing" c) Apply his Value Added[tm] patches to "testing". Once he is happy with the result in c), he would pull the "testing" changes into his "master" branch and continue on to step 3)
I don't see any major advantage of this, but it would be helpful for keeping the patches straight if branches needed to be discarded and recreated due to state 4-bad).
On Wed, 02 Jan 2008 15:52:17 -0500 Jerry Van Baren gerald.vanbaren@ge.com wrote:
4-bad) In a worst case scenario, Wolfgang requires changes to the u-boot-fdt patches.
This really shouldn't happen very often. Any problems with the patches should be sorted out during review on the list, so everything that ends up as part of a pull request should be acceptable.
Of course, it sometimes happens that a pull request is rejected, but it should be the exception rather than the rule.
Haavard
participants (7)
-
Andy Fleming -
Andy Fleming -
Haavard Skinnemoen -
Jerry Van Baren -
Rafal Jaworowski -
Stefan Roese -
Wolfgang Denk