From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Wed, 22 Oct 2014 09:55:14 +0200 Subject: [U-Boot] [RFC] MW rule and its period In-Reply-To: References: Message-ID: <544762E2.9040505@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Otavio, On 21/10/2014 21:14, Otavio Salvador wrote: > On Tue, Oct 21, 2014 at 4:07 PM, Masahiro YAMADA > 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 =====================================================================