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