From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 20 Nov 2007 13:05:39 -0500 Subject: [U-Boot-Users] PATCHES for next Merge Window In-Reply-To: <1195580562.25887.9.camel@ld0161-tx32> References: <20071120134135.0DB9C2479C@gemini.denx.de> <1195580562.25887.9.camel@ld0161-tx32> Message-ID: <474321F3.9090201@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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