[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Dirk,

In message <49F2B6B9.7040300 at googlemail.com> you wrote:
> 
> > 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.

Mine, too. Note however that I will not always and not  automatically
and  not exactly at the end of the merge window create a next branch,
but I'm in a somewhat specialposition anyway.

> 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?

They can, if the custodian accepts it, and.or if there is consensus on
the ML.

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

These should go in. People who put a lot of effort in their  planning
should not suffer from the fact that a custodian is slow on answering
or reviewing their patches. Everything that has been sent to the list
before the end of the MW should go in.

> - 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'.

Patch acceptance is not as critical as a financial transaction, or
such. So if there is a slight delay, the custodian is free to turn a
blind eye and accept it anyway.  The idea of the development process
is to make it foreseeable and plannable, but not to become a PITA or
to slow down development.

It makes much more sense if an engineer spends another day on testing
and cleanup and submits the patch a couple of hours late, instead  of
submitting a green patch which will waste efforts from several prople
during several rounds of review and reposts.

> 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'.

But this should be clear: if sent while the merge indow is open, new
stuff can go in. If the MW is closed, new stuff may go into next (if
the respective custodian runs a next branch), otherwise it has to wait
until the next MW.  Bug fixes can go in any time.

> 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 agree that this is not nice.

In any case,  there  should  be  some  comment  from  the  respective
custodian which makes *clear* what the patch state is. Even a "I have
no  time  now, will look into it later" is better than nothing. Also,
if there are remarks to a patch, these should leave no doubt if  they
were  just  comments and the patch will be accepted anyway, or if the
patch should be reworked/resubmitted, or if the  patch  was  rejected
without chance to be included at all.

> > I can't say for sure if this is how all branches are
> > handled, though.
> 
> Let's wait for Jean-Christophe opinion.

Well, his opinion is one thing. But I think we can also  expect  from
Jean-Christophe  as  ARM  custodian that he delivers clear and under-
standable feedback to all patch submitters.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Make it right before you make it faster.