[U-Boot] U-Boot ARM merge strategy

[Ben Warren]

Hi Dirk,

Dirk Behme wrote:
> Hi Ben,
>
> Ben Warren wrote:
>> Hi Dirk,
>>
>> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme 
>> <dirk.behme at 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?
>
I agree that cleanup patches should have more flexibility.
> - What's about patches that are sent while open merge window or 
> before, but need some update cycles and are finalized while rc?
>
My policy is to look at the timestamp of the first revision.  If it's 
during the merge window, follow-on versions are OK too.
> - 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'.
>
Well, since communication about the window state is rare at best, a good 
argument can be made for flexibility here.
> 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'.
>
Sure - consistency would be great.  Unfortunately every custodian has 
his own approach and it's a volunteer workforce.  Definitely a goal 
worth pursuing, though.
> 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.
>
Yeah, better and quicker feedback is a goal we should all be working 
towards.  Obviously small, trivial patches are easier to review than new 
drivers, and so are typically applied more quickly.
>> 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
>
regards,
Ben