[U-Boot-Users] PATCHES for next Merge Window

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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