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

[Masahiro YAMADA]

Hi Tom,



2014-10-28 1:59 GMT+09:00 Tom Rini <trini at ti.com>:
> On Tue, Oct 21, 2014 at 09:34:11PM +0200, Wolfgang Denk wrote:
>> Dear Masahiro,
>>
>> In message <CAMhH57R2eBf26ONYD4fnLRWDQ=Bjy_0CRLM_yOPrZGdMwOQF9g at mail.gmail.com> you wrote:
>> >
>> > Even Linux needs 7 weeks to be stabilized
>> > in spite of much more commits than U-Boot.
>> >
>> > Do we really need 10 weeks?
>>
>> I think a fundamental difference between Linux and U-Boot is that in
>> Linux the actual core is not changing so heavily, and the individual
>> subsystems are much better isolated.  In U-Boot, we have a large
>> number commits with architecture-wide impact, not to mention
>> system-wide ones like the Kconfig / Kbuild or DM restructuring.
>> So a bug introduced in Linux will often affect only a relatively small
>> group of developers, while the rest can continue working basically
>> unaffected.  In U-Boot it's easy to break all ARM, which will bring
>> the majority of developers to a full stop.
>>
>> Also I think reducing the MW makes things indeed faster, which means
>> more frequent release cycles, and I'm afraid in the end the custodians
>> will not find their days easier, but more loaded.
>
> Well, here's what I've noticed.  We have a relative flury of activity
> around the merge window, then we have a period of both "bending" the
> window and having some folks be frustrated about their patches not being
> anywhere followed by a release.  It's true we're making changes which
> can break more core areas, but just how much testing are people doing on
> top of tree? rc releaes?
>
> I wonder about for 2015 if having some shorter merge window and release
> schedule might not help, especially with planning peoples time.  If say
> releases were the last Friday of even numbered months (Feb 27, Apr 24,
> June 26, Aug 28, Oct 30, Dec 25 (eep, OK, re-jigger that one..)), final
> RC Monday 2 weeks prior, RC every 2 weeks before then, only final RC is
> bug fix (here's how to trigger, here's fix kind), everything else is
> best judgement.  Or even first week of the month is for big scary
> changes, last week is bug fixes, rest is best judgement monthly release
> cycle.  It wouldn't be terrible for $SOC to have patches miss the April
> release since May is right around the corner.  Custodians would know if
> they can focus some time the second week of the month of U-Boot for
> "regular" patches they can then come around the last week of the month,
> run test a few boards and be Good to Go.


Shorter release cycle works for me.

My understanding of Detlev's memo was only bug fixes can go in after rc1,
but you state everything is best judgement except final rc.
That means we do not have to be so strict as Linux Kernel, right?




-- 
Best Regards
Masahiro Yamada