PATCHES for next Merge Window
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2 - after such a significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
In any case, after that probably all patches have to be rebased against the new tree - otherwise we would run into a lot of nasty merge conflicts.
Best regards,
Wolfgang Denk
Signature · 4 lines
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 Sex is like air. It's only a big deal if you can't get any.
Quoted 8 lines · Wolfgang Denk
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
Quoted 8 lines
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2 - after such a significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
Here's the updated pull request for my patches:
The following changes since commit 9a337ddc154a10a26f117fd147b009abcdeba75a:
Wolfgang Denk (1):
Prepare for 1.3.0 release.
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc5xxx.git kconfig-for-1.3.1
Grant Likely (10):
Add .gitignore files
Build: split COBJS value into multiple lines Group network drivers in drivers/Makefile Group console drivers in drivers/Makefile Group i2c drivers in drivers/Makefile Group USB drivers in drivers/Makefile Group block/flash drivers in drivers/Makefile Group PCI and PCMCIA drivers in drivers/Makefile Merge branch 'origin' into kconfig-for-1.3.1 Merge branch 'origin' into kconfig-for-1.3.1
.gitignore | 13 ++++ common/Makefile | 123 +++++++++++++++++++++++++++++++-------- disk/Makefile | 7 ++- drivers/Makefile | 143 +++++++++++++++++++++++++++++++++++++--------- drivers/nand/Makefile | 10 +++- drivers/sk98lin/Makefile | 26 +++++++-- dtt/Makefile | 7 ++- examples/.gitignore | 5 ++ fs/jffs2/Makefile | 12 +++- include/.gitignore | 6 ++ lib_generic/Makefile | 21 +++++-- libfdt/Makefile | 4 +- net/Makefile | 11 +++- rtc/Makefile | 30 ++++++++-- tools/.gitignore | 9 +++ 15 files changed, 347 insertions(+), 80 deletions(-)
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
Quoted 20 lines · Grant Likely
Quoted 8 lines · Wolfgang Denk
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
Quoted 8 lines
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2 - after such a significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
Here's the updated pull request for my patches:
Quoted 8 lines
The following changes since commit
9a337ddc154a10a26f117fd147b009abcdeba75a:
Wolfgang Denk (1):
Prepare for 1.3.0 release.are available in the git repository at:
git://www.denx.de/git/u-boot-mpc5xxx.gitkconfig-for-1.3.1
I will send the drivers reorganisation patch before Friday.
If I've time tomorrow morming.
Best Regards,
J.
Quoted 10 lines · In message <[email protected]> you…
Here's the updated pull request for my patches:
The following changes since commit
9a337ddc154a10a26f117fd147b009abcdeba75a:
Wolfgang Denk (1):
Prepare for 1.3.0 release.are available in the git repository at:
git://www.denx.de/git/u-boot-mpc5xxx.gitkconfig-for-1.3.1
Merged into u-boot-testing repository.
Jean-Christophe - that's your base for the drivers reorganisation patches.
Best regards,
Wolfgang Denk
Signature · 4 lines
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 Any technology distinguishable from magic is insufficiently advanced.
Quoted 17 lines · Wolfgang Denk
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2 - after such a significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
Quoted 3 lines
In any case, after that probably all patches have to be rebased against the new tree - otherwise we would run into a lot of nasty merge conflicts.
How long will that mean in terms of taking any actual new code between when the merge window closed for 1.3.0 and the 1.3.3 or 1.4.0 window opening? Seems like it will be a very long time.
- k
Quoted 20 lines · Kumar Gala
Quoted 17 lines · Wolfgang Denk
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2 - after such a significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
Quoted 7 lines
Quoted 3 lines
In any case, after that probably all patches have to be rebased against the new tree - otherwise we would run into a lot of nasty merge conflicts.
How long will that mean in terms of taking any actual new code between when the merge window closed for 1.3.0 and the 1.3.3 or 1.4.0 window opening? Seems like it will be a very long time.
My patches are ready to be pulled and merged by Wolfgang now. The rebase/merge that everyone will need to do is to ease the pain of the Makefile changes. It's the sort of fixups that are a lot easier if the custodians do them rather than Wolfgang having to figure it all out.
I wouldn't be surprised if the new merge window should be openable in less than a day. The next question is how long should the window be open?
Cheers,
g.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
Quoted 7 lines · Wolfgang Denk
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
I'm not sure exactly what you are meaning here. To be clear, I'd like to call out two separate functions of the custodians and their repos and see if you (Wolfgang and others) buy it.
While you (Wolfgang) are in the "stabilizing a release" mode, it should be the time for the custodians to be gathering and staging their patches into a repo so that they can be pulled when a merge window opens. So to that end, the custodians are not waiting.
But yes, if you (Wolfgang) are not yet ready to generally pull from custodians, or have a planned order for that, then, yes, it does make sense for the custodians to wait to issue "pull requests" until you are ready for them.
Quoted 4 lines
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2
Did I miss 1.3.1 already?
Quoted 5 lines
- after such a
significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
I'd like to have the new libfdt structure in place too, as a general goal for us is to move all the FSL boards over to it in "the next" U-Boot release. (For some value of "the next", of course. :-))
Thanks,
jdl
Quoted 39 lines · Jon Loeliger
Quoted 7 lines · Wolfgang Denk
Hello to everybody...
...who has sumbitted new patches without waiting for the official opening of the new merge window.
Please note that I will NOT apply any of these patches yet. And I recommend all custodians to wait, too.
I'm not sure exactly what you are meaning here. To be clear, I'd like to call out two separate functions of the custodians and their repos and see if you (Wolfgang and others) buy it.
While you (Wolfgang) are in the "stabilizing a release" mode, it should be the time for the custodians to be gathering and staging their patches into a repo so that they can be pulled when a merge window opens. So to that end, the custodians are not waiting.
But yes, if you (Wolfgang) are not yet ready to generally pull from custodians, or have a planned order for that, then, yes, it does make sense for the custodians to wait to issue "pull requests" until you are ready for them.
Quoted 4 lines
The plan is as follows:
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2
Did I miss 1.3.1 already?
Quoted 5 lines
- after such a
significant restructuring I'd rather want to have it tested and cleaned up first before adding more new stuff. Let's do a quick cycle for 1.3.2 (which would be also good to bring us back in sync with the Linux cycle).
Quoted 7 lines
I'd like to have the new libfdt structure in place too, as a general goal for us is to move all the FSL boards over to it in "the next" U-Boot release. (For some value of "the next", of course. :-))
Thanks,
jdl
You mean, for a *sufficiently small* value of "next." :-D
I'm planning to get libfdt improvements into the next release (1.3.1). My plan is to stage the libfdt improvements in a "testing" branch (I'm starting down that path, but have not pushed anything back to denx.de yet). When the window opens and Grant's changes get pulled in, I will rebase and then pull the libfdt "testing" branch into my "master" branch. If Something Bad[tm] happens with the rebase, it is NBD, the files would have to be fixed anyway and branches are cheap. Once that works, I'll issue a call to Wolfgang to pull.
The nice things about git are...
1) It is easy to make a clone of a repo
2) It is easy to make a branch in a repo
3) It is easy to rebase a branch
4) It is easy to throw away a branch or repo when you screw up :-O
As long as you remember to do (1) and/or (2) before doing something "irreversible", (4) pulls your bacon out of the fire. ;-)
gvb
Dear Jon,
Quoted 6 lines · in message <1195580562.25887.9.camel@ld0161-tx32> you wrote:
While you (Wolfgang) are in the "stabilizing a release" mode, it should be the time for the custodians to be gathering and staging their patches into a repo so that they can be pulled when a merge window opens. So to that end, the custodians are not waiting.
Normally, this is correct. But normally, patches are usually more or less orthogonal, and stuff that touches the same area goes through the one specific custodian who coordinates this.
This time, situation is completely different. We touch a pretty fundamental part of the global infrastructure. Anybody who does not wait will probably be hit hard,
Quoted 4 lines
Quoted 2 lines
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2
Did I miss 1.3.1 already?
No, that's just my fingers being faster than my brain. Which doesn't imply that they were especially fast.
Quoted 4 lines
I'd like to have the new libfdt structure in place too, as a general goal for us is to move all the FSL boards over to it in "the next" U-Boot release. (For some value of "the next", of course. :-))
I definitely don;t intend to delay the U-Boot development if it can be avoided. But with the Makefile reorganization *and* the driver restructuring we have two global changed which affect nearly everybody.
I really think it makes sense to define some checkpoint after these changes and verify that nothing was broken before adding many new patches to different areas which will hide all traces.
So my idea is really to have a very short semi-open merghe window (just long enough until Jean-Christophe has the drivers reorgani- zation patches ready - he said that's Friday.
So assume we will have a 1.3.1-rc1 by Sunday, and 1.3.1 released by Friday next week. Or so - if nothing goes wrong.
And then we formally open a real new merge window.
What do you think?
Best regards,
Wolfgang Denk
Signature · 6 lines
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
"...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head."
- Larry Wall in <[email protected]>Quoted 44 lines · On Tue, 20 Nov 2007 21:26:27 +0100 Wolfgang Denk <[email protected]> wrote:
Dear Jon,
Quoted 6 lines · in message <1195580562.25887.9.camel@ld0161-tx32> you wrote:
While you (Wolfgang) are in the "stabilizing a release" mode, it should be the time for the custodians to be gathering and staging their patches into a repo so that they can be pulled when a merge window opens. So to that end, the custodians are not waiting.
Normally, this is correct. But normally, patches are usually more or less orthogonal, and stuff that touches the same area goes through the one specific custodian who coordinates this.
This time, situation is completely different. We touch a pretty fundamental part of the global infrastructure. Anybody who does not wait will probably be hit hard,
Quoted 4 lines
Quoted 2 lines
Grant Likely's patches come first, then comes the drivers reorgani- zation, and I tend to say that's what goes into 1.3.2
Did I miss 1.3.1 already?
No, that's just my fingers being faster than my brain. Which doesn't imply that they were especially fast.
Quoted 4 lines
I'd like to have the new libfdt structure in place too, as a general goal for us is to move all the FSL boards over to it in "the next" U-Boot release. (For some value of "the next", of course. :-))
I definitely don;t intend to delay the U-Boot development if it can be avoided. But with the
Makefilereorganization *and* the driver restructuring we have two global changed which affect nearly everybody.I really think it makes sense to define some checkpoint after these changes and verify that nothing was broken before adding many new patches to different areas which will hide all traces.
So my idea is really to have a very short semi-open merghe window (just long enough until Jean-Christophe has the drivers reorgani- zation patches ready - he said that's Friday.
Quoted 6 lines
So assume we will have a 1.3.1-rc1 by Sunday, and 1.3.1 released by Friday next week. Or so - if nothing goes wrong.
And then we formally open a real new merge window.
What do you think?
Not that I have any stake in this, but that seems overly cautious. Just declare that the driver reorganization/makefile changes are the first thing to be merged and make the maintainers rebase after.
I don't see a need for a whole separate release.
josh
Quoted 11 lines · Josh Boyer
Quoted 9 lines · On Tue, 20 Nov 2007 21:26:27 +0100 Wolfgang Denk <[email protected]> wrote:
So my idea is really to have a very short semi-open merghe window (just long enough until Jean-Christophe has the drivers reorgani- zation patches ready - he said that's Friday.
So assume we will have a 1.3.1-rc1 by Sunday, and 1.3.1 released by Friday next week. Or so - if nothing goes wrong.
And then we formally open a real new merge window.
Quoted 7 lines
Quoted 1 line
What do you think?
Not that I have any stake in this, but that seems overly cautious. Just declare that the driver reorganization/makefile changes are the first thing to be merged and make the maintainers rebase after.
I don't see a need for a whole separate release.
Personally, I'm not at all concerned about it. There isn't a lot of risk in my changes; just merge pain if it's done out of order. I'm not opposed to a quick merge cycle for these changes, but I don't think it's strictly necessary either.
Cheers,
g.
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely at secretlab.ca (403) 399-0195
Quoted 6 lines · Wolfgang Denk
Dear Jon,
And then we formally open a real new merge window.
What do you think?
Sounds good to me!
jdl