[U-Boot] [RFC] MW rule and its period

[Masahiro YAMADA]

Hello,

The following is the notes of the open discussion sent by Detlev:

> The fact that a large set of patches for the SoCFPGAs was merged after
> -rc1 was questioned as it does not 100% comply with the rules.  The
> patches constrained to SoCFPGA were no (big) problem, but one of those
> patches broke mkimage and as such had an impact on the whole project.
>
> The lesson should be - custodians should send out pull requests soon
> after the merge window opens up.  Big chunks should not be pulled in
> after -rc1.
>
> The -next branch should be declared rebaseable and be used more.
> Once -rc1 is released, things can then be pulled into the next
> branch.  Only bug fixes should go into the later -rc's.


I think this statement means we should be more strict to the merge window rule.

I think, basically, our (= developers') pain depends on the duration
of the merge
window being _closed_.
(The duration of the merge window, if it is 2 weeks or 3 weeks, it is
not a big deal.)

The longer the merge window is closed, the more master and next branch diverge,
i.e. more possible conflicts we get.


In Linux,
 2 weeks open
 7 (sometimes 8) weeks closed

In U-boot, released every 3months(=13 week)
 3 weeks open
 10 weeks closed


Even Linux needs 7 weeks to be stabilized
in spite of much more commits than U-Boot.

Do we really need 10 weeks?

If we make a decision to adopt a more strict merge window rule,
shall we discuss how long it should be opened and closed?
(although I still prefer the former loose MW rule...)

(As Linus said in ELCE2014, if the release cycle is short,
it does not matter even if you miss a merge window;
just wait, next merge window comes soon. )


So two options here I'd like to suggest

[1] Every 2 months release with 2 weeks MW

MW open: 2 weeks
MW closed: 6.5 weeks

[2] Every 3 months release with 7 weeks MW

MW open: 7 weeks
MW closed: 6 weeks



Comments?


-- 
Best Regards
Masahiro Yamada