From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Boyer Date: Tue, 20 Nov 2007 14:49:20 -0600 Subject: [U-Boot-Users] PATCHES for next Merge Window In-Reply-To: <20071120202628.0D092246B5@gemini.denx.de> References: <1195580562.25887.9.camel@ld0161-tx32> <20071120202628.0D092246B5@gemini.denx.de> Message-ID: <20071120144920.4b0c9d42@weaponx> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 20 Nov 2007 21:26:27 +0100 Wolfgang Denk 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