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

[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

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

[Otavio Salvador]

On Tue, Oct 21, 2014 at 4:07 PM, Masahiro YAMADA
<yamada.m@jp.panasonic.com> wrote:
...
> 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

I prefer this option however I also want to warn this will impose more
active response from custodians. In case of the i.MX we had long
delays in review and merges from Stefano from time to time and this
would complicate a lot.

So for i.MX specific case some patches got merged late and this
complicates a lot testing. Mainly because sometimes one tree depends
on changes in another and a lack of u-boot-next where all them are
automatic merged complicates a full test of upcoming release.

p.s: this is not a personal attack but something which is clearly happening.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

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

[Wolfgang Denk]

Dear Masahiro,

In message <CAMhH57R2eBf26ONYD4fnLRWDQ=Bjy_0CRLM_yOPrZGdMwOQF9g@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.

Just my $0.02.

> 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

I think 2 (...3) weeks of MW work pretty well for U-Boot; we should
not need more.  Keeping the MW open too long just increases to efforts
to make everything ready for release.  So in my opinion it boild sown
if we want to shorten the release cycle as such.  I guess we whould
have to try it out, but I fear it might easily backfire.

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
The flow chart is a most thoroughly oversold piece of  program  docu-
mentation.              -- Frederick Brooks, "The Mythical Man Month"

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

[Stefano Babic]

Hi Otavio,

On 21/10/2014 21:14, Otavio Salvador wrote:
> On Tue, Oct 21, 2014 at 4:07 PM, Masahiro YAMADA
> <yamada.m@jp.panasonic.com> wrote:
> ...
>> 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
> 
> I prefer this option however I also want to warn this will impose more
> active response from custodians. In case of the i.MX we had long
> delays in review and merges from Stefano from time to time and this
> would complicate a lot.
> 

Please understand that work as u-boot custodian is done by me (and by
other custodians) in our spare time, and depending on our current load
this time can be smaller as desired.

> So for i.MX specific case some patches got merged late and this
> complicates a lot testing.

I confess I have been not so strict regarding merge window and its
rules: if I can merge a patchset without affecting a lot the rest of
U-Boot, I tend to do it, even if patches were sent later. This seems a
common problem, as the thread was originated by socFPGA patches. We have
to decide now if we should be more strict with merge window rule or not.
However, this can bring that new features will be delayed to next releases.

> Mainly because sometimes one tree depends
> on changes in another

This is due to the fact that subsystems and/or SOCs cannot be easy
isolated. Sometimes it is also not clear who is the custodian
responsible for a patch, and sometimes the same patchset is split into
several are of competences.

> and a lack of u-boot-next where all them are
> automatic merged complicates a full test of upcoming release.

This can help, but we need to define how conflicts are then resolved and
who take care of them. Without defining those rules, it does not help a lot.

> 
> p.s: this is not a personal attack but something which is clearly happening.

Of course - we are trying all together to make the whole process better ;-)

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

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

[Otavio Salvador]

On Wed, Oct 22, 2014 at 5:55 AM, Stefano Babic <sbabic@denx.de> wrote:
> On 21/10/2014 21:14, Otavio Salvador wrote:
>> On Tue, Oct 21, 2014 at 4:07 PM, Masahiro YAMADA
>> <yamada.m@jp.panasonic.com> wrote:
>> ...
>>> 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
>>
>> I prefer this option however I also want to warn this will impose more
>> active response from custodians. In case of the i.MX we had long
>> delays in review and merges from Stefano from time to time and this
>> would complicate a lot.
>>
>
> Please understand that work as u-boot custodian is done by me (and by
> other custodians) in our spare time, and depending on our current load
> this time can be smaller as desired.

Yes but we could have a 'backup' custodian or so to avoid these delays.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

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

[Masahiro YAMADA]

Hi.



2014-10-22 4:34 GMT+09:00 Wolfgang Denk <wd@denx.de>:
> Dear Masahiro,
>
> In message <CAMhH57R2eBf26ONYD4fnLRWDQ=Bjy_0CRLM_yOPrZGdMwOQF9g@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.

Agreed, but a large number of global changes also means conflicts
between the master and the next branch if we close the MW for a long time.

Just my two yen.  :-)




>> 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
>
> I think 2 (...3) weeks of MW work pretty well for U-Boot; we should
> not need more.  Keeping the MW open too long just increases to efforts
> to make everything ready for release.  So in my opinion it boild sown
> if we want to shorten the release cycle as such.  I guess we whould
> have to try it out, but I fear it might easily backfire.
>

I think efforts for release preparation would not be so different.

If we shortened the release cycle, everyone would more focus on the
short-term development; big changes such as Kconfig, DM would become difficult.
I prefer [2].

Or another option I've come up with is
[3] Every 3 months release with two levels of MW

    - rc1: 3 weeks:  MW is "widely" open
      Giant changes (such as Kconfig switch) are only applicable
during this period

rc1 - rc2: 3 weeks:  MW is still "slightly" open
       Small or SoC-specific changes are still merged to the master branch

rc2 - release:       MW is really closed
       Only bug fixes are merged to the master branch




-- 
Best Regards
Masahiro Yamada

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

[Tom Rini]

On Tue, Oct 21, 2014 at 09:34:11PM +0200, Wolfgang Denk wrote:
> Dear Masahiro,
> 
> In message <CAMhH57R2eBf26ONYD4fnLRWDQ=Bjy_0CRLM_yOPrZGdMwOQF9g@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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141027/52260fb1/attachment.pgp>

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

[Masahiro YAMADA]

Hi Tom,



2014-10-28 1:59 GMT+09:00 Tom Rini <trini@ti.com>:
> On Tue, Oct 21, 2014 at 09:34:11PM +0200, Wolfgang Denk wrote:
>> Dear Masahiro,
>>
>> In message <CAMhH57R2eBf26ONYD4fnLRWDQ=Bjy_0CRLM_yOPrZGdMwOQF9g@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