From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 47349E00961; Mon, 27 Apr 2015 21:14:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A844FE008EA for ; Mon, 27 Apr 2015 21:14:15 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id 34102600205C; Tue, 28 Apr 2015 07:14:13 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1430194453; bh=03Y2Fazh8pQrVGgTt4FyamtCYsIqwvJCGx6WEUGsR54=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=g22ln8UpPujo5mxsamG3uk+VvNpfZBYB3ffIaujE5TmpbmGdCTKCCERnWSsQsb6kN pIhWp0MVQ9EQKSX/TUImAMVdOEhF51N2pcJJ4OjKs/jBH7xU5aXjzHjwpVhPoesUZg gL8dYocH83bxHqHA/9TZnDjXXNZup84juCPhhDjE= Message-ID: <553F0915.5090609@mail.bg> Date: Tue, 28 Apr 2015 07:14:13 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Otavio Salvador , Daiane Angolini References: <1430109302-25721-1-git-send-email-picmaster@mail.bg> <553E5556.9070406@mail.bg> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm-extra][PATCH 1/2] linux-riotboard: Add separate riotboard kernel recipe X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 04:14:23 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daiane, Otavio, On 04/27/2015 07:59 PM, Otavio Salvador wrote: > On Mon, Apr 27, 2015 at 1:54 PM, Daiane Angolini > wrote: >> On Mon, Apr 27, 2015 at 1:26 PM, Otavio Salvador >> wrote: >>> On Mon, Apr 27, 2015 at 12:27 PM, Nikolay Dimitrov >>> wrote: >>>> On 04/27/2015 02:40 PM, Otavio Salvador wrote: >>>>> >>>>> Hello Nikolay, >>>>> >>>>> On Mon, Apr 27, 2015 at 1:35 AM, Nikolay Dimitrov >>>>> wrote: >>>>>> >>>>>> Add dedicated RIoTboard kernel recipe for easier >>>>>> maintenance and patch cherry-picking. >>>>>> >>>>>> Signed-off-by: Nikolay Dimitrov >>>>> >>>>> >>>>> I want to check with you if you really want to have a >>>>> dedicated recipe. For bugfixes (as now) you can use a >>>>> bbappend as a temporary solution and, at end of the day, easy >>>>> to remove once this is fixed in the kernel. >>>>> >>>>> Please let me know your thoughts... >>>> >>>> >>>> Do you mean something like this (bbappend in >>>> meta-fsl-arm-extra)? >>>> >>>> diff --git a/recipes-kernel/linux/linux-fslc_4.0.bbappend >>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend new file mode >>>> 100644 index 0000000..d7a4e72 --- /dev/null +++ >>>> b/recipes-kernel/linux/linux-fslc_4.0.bbappend @@ -0,0 +1,3 @@ >>>> +FILESEXTRAPATHS_append := ":${THISDIR}/${PN}" + >>>> +SRC_URI_imx6dl-riotboard = "file://riotboard-specific.patch" >>> >>> Yes. >>> >>>> Well, imho the difference between bbappending and having a >>>> separate recipe is that the bbappending mechanism is >>>> retro-reactive - I can bbappend patches to linux-fslc but in >>>> the meantime the board support will be broken. >>>> >>>> Maintaining a separate kernel recipe for riotboard is a >>>> proactive way, imho. When linux-fslc updates are happening, >>>> they won't immediately break the riotboard, and after I test >>>> the updates I can update SRC_REV to point it to a specific >>>> working commit, or as in my case point SRC_REV to the latest >>>> commit and revert just one specific patch. The advantage is >>>> that all the time the board support will be working. >>>> >>>> This was my motivation for the patch. Please tell me if there >>>> are any drawback of having a separate board kernel recipe. >>> >>> Maintenance burden. >>> >>> Your thought is right but what should have been done was people >>> to report this issue when we included 4.0 recipe. >>> >>> For now a bbappend would work as a band-aid while the real fix >>> is being cooked. I usually do not do design for the exception >>> and I believe linux-fslc once fixed will be kept working for the >>> board. >>> >>> This is really up to you but I think a boot test every time we >>> prepare a bump linux-fslc would be enough to iron out the need of >>> a specific recipe. >> >> Otavio, I really don't like to see more and more linux providers >> on top of linux-fslc. We already have too much linux providers. @Daiane, would you like to elaborate on this? >> For me it looks like a temporary fix being assumed mainline. > > So the bbappend for a workaround while linux-fslc is proper fixed > seems to be the way to go. I second your view I also prefer to not > have many kernel providers except if there are real reasons for it. > In Linux mainline case I see none. > OK. Regards, Nikolay