[U-Boot-Users] 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
On Nov 20, 2007, at 7:41 AM, Wolfgang Denk wrote:
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.
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
On 11/20/07, Kumar Gala galak@kernel.crashing.org wrote:
On Nov 20, 2007, at 7:41 AM, Wolfgang Denk wrote:
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.
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.
On 11/20/07, Wolfgang Denk wd@denx.de wrote:
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).
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(-)
On 08:24 Tue 20 Nov , Grant Likely wrote:
On 11/20/07, Wolfgang Denk wd@denx.de wrote:
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).
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
I will send the drivers reorganisation patch before Friday.
If I've time tomorrow morming.
Best Regards, J.
In message fa686aa40711200724q4ebac2bdtf3a4b9ac7b0a899b@mail.gmail.com you wrote:
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
Merged into u-boot-testing repository.
Jean-Christophe - that's your base for the drivers reorganisation patches.
Best regards,
Wolfgang Denk
On Tue, 2007-11-20 at 07:41, Wolfgang Denk wrote:
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.
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?
- 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
Jon Loeliger wrote:
On Tue, 2007-11-20 at 07:41, Wolfgang Denk wrote:
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.
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?
- 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
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,
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,
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.
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
On Tue, 20 Nov 2007 21:26:27 +0100 Wolfgang Denk wd@denx.de wrote:
Dear Jon,
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,
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.
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?
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
On 11/20/07, Josh Boyer jwboyer@gmail.com wrote:
On Tue, 20 Nov 2007 21:26:27 +0100 Wolfgang Denk wd@denx.de 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.
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.
participants (7)
-
Grant Likely -
Jean-Christophe PLAGNIOL-VILLARD -
Jerry Van Baren -
Jon Loeliger -
Josh Boyer -
Kumar Gala -
Wolfgang Denk