All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] MW rule and its period
Date: Wed, 22 Oct 2014 09:55:14 +0200	[thread overview]
Message-ID: <544762E2.9040505@denx.de> (raw)
In-Reply-To: <CAP9ODKpi=RHhpEy=1ymj24Ma--+gNXoY6v=7ymK_bSMn0MnCeA@mail.gmail.com>

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

  reply	other threads:[~2014-10-22  7:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21 18:07 [U-Boot] [RFC] MW rule and its period Masahiro YAMADA
2014-10-21 19:14 ` Otavio Salvador
2014-10-22  7:55   ` Stefano Babic [this message]
2014-10-22 18:14     ` Otavio Salvador
2014-10-21 19:34 ` Wolfgang Denk
2014-10-26 17:35   ` Masahiro YAMADA
2014-10-27 16:59   ` Tom Rini
2014-10-28 16:34     ` Masahiro YAMADA

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=544762E2.9040505@denx.de \
    --to=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.