[U-Boot] U-Boot ARM merge strategy

[Dirk Behme <dirk.behme@googlemail.com>]

Hi Ben,

Ben Warren wrote:
> Hi Dirk,
> 
> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme <dirk.behme@googlemail.com>wrote:
> 
>> Dear Jean-Christophe,
>>
>> David Brownell wrote:
>> ...
>>>>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>>>> the Patch series and this has been apply in the u-boot-arm/next
>>> I see that branch now exists ... thanks!  :)
>> ....
>>> Could you clarify the current merge cycle for me, by the way?
>>> I know u-boot has switched to 2009.{01,03,05,...} releases,
>>> which is a big win from where I sit!, with "rc" tags.
>>>
>>> What I'm unclear on is what gets merged for 2009.05 versus
>>> later.  Are these "next" branches for the '05 release (which
>>> hasn't yet hit rc1)?  Or for '07 instead?
>> Yes, I have the same questions. I already tried to ask similar, but
>> didn't get an answer.
>>
>> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
>>
>> Maybe my wording was a little unclear?
>>
>> Dirk
>>
>> Btw.: Now that -next exists, I can't find patch linked above in it,
>> though :(
>>
> 
> My approach is that once the merge window closes, new patches that are not
> bug fixes go into 'next', which is for the release after the current one (in
> this case 07).  When the merge window opens again, next goes to master and
> the fun starts again.

Yes, this is my basic understanding, too.

But there are always these ugly details ;)

- What's about patches that remove dead code, unused macros etc. IMHO 
they can be handled like bug fixes and applied while rc?

- What's about patches that are sent while open merge window or 
before, but need some update cycles and are finalized while rc?

- What about patches which are sent immediately after merge window 
closed (hours - 1 or 2 days)? I already heard something like 'no 
problem if it comes some hours later, if it is fine then I will still 
apply it'.

What I personally find essential for patch submitters is the patch 
dealing by custodian. It should be consistent and by this somehow 
predictable. This helps patch submitters to get a feeling for 'this 
patch has only a chance while merge window is open' or 'it's worth 
sending this patch immediately, it will have a chance to be merge now'.

What confuses me is something like patch A is applied short time after 
sent, patch B will be eventually applied later to next, patch C gets 
no comments. With A and B doing the same stuff, and maybe C sent before A.

> I can't say for sure if this is how all branches are
> handled, though.

Let's wait for Jean-Christophe opinion.

Best regards

Dirk