From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 287A8E007A0; Mon, 6 Apr 2015 13:51:02 -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.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.192.180 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id D1DC9E006E6 for ; Mon, 6 Apr 2015 13:51:00 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so55729475pdb.0 for ; Mon, 06 Apr 2015 13:50:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XBFDzpARcMXkBnyZlh34086sIAUcptF9ay8lsyQDSfo=; b=i99CYEKz99u8LqbrvwiqcUq2CdwkJoYJPiXI4GBddQkLiUjmI9GUwfSjOm7rNxEZ9y 8jsMZgKhH5UfJNLLZ7bdZACzVQrINnP81qLJkvJ8mXMa+5AfCGShH/EJppC3x+RTq8HM 6RxKOdYEIaaGKLRhJqdGJyu2lDXfOUKLPAmdrF/3h56VBSS+/6QHoz4vxb+PbVquZds2 8Vo0I/oUoRBhaMhzzrJCmHoY9/JikrWtLcjzVjlX7iSlZxzFXLSZ+5sl+/wMcJ89mAMV KgFrmcNYp6bbnDS70lHJElWPcorGLUjasw8/tJD7Xzvs91ZF9nla81FicEI9JbcMpwWd HeSQ== X-Gm-Message-State: ALoCoQmR77kCqOiqywctZanodz/04Ns9efoxpEaDoL4na3NxZbYLKHrUxZAXx68q5DZXUTa2JhBP X-Received: by 10.70.61.202 with SMTP id s10mr30365153pdr.86.1428353459827; Mon, 06 Apr 2015 13:50:59 -0700 (PDT) Received: from [192.168.1.109] (wsip-70-184-93-199.ph.ph.cox.net. [70.184.93.199]) by mx.google.com with ESMTPSA id tm6sm5618941pbc.7.2015.04.06.13.50.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2015 13:50:58 -0700 (PDT) Message-ID: <5522F1B0.4070508@boundarydevices.com> Date: Mon, 06 Apr 2015 13:50:56 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Otavio Salvador References: <1428007119-13395-1-git-send-email-lauren.post@freescale.com> <1428007119-13395-2-git-send-email-lauren.post@freescale.com> <5522E96F.2060507@boundarydevices.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH 01/11] linux-imx: Upgrade to 3.14.28-1.0.0 GA version 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: Mon, 06 Apr 2015 20:51:02 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Otavio, On 04/06/2015 01:38 PM, Otavio Salvador wrote: > On Mon, Apr 6, 2015 at 5:15 PM, Eric Nelson > wrote: >> Hi Otavio and Lauren, >> >> On 04/06/2015 09:26 AM, Otavio Salvador wrote: >>> On Mon, Apr 6, 2015 at 12:36 PM, Lauren Post wrote: >>>> 3.10.53 only exists in master branch now so to remove it means it will not exist on any branch. >>> >>> It exists in Git so if someone ever wants or need it, can easily >>> revert the patch and use. >>> >>>> In past we only removed kernel versions that exist in other branches. >>> >>> It was just by coincidence because of the release cadence matched the branching. >>> >>>> I believe it is best to leave 3.10.53 and remove in master branch after fido branch is created. >> >> What's the plan for the default FSL kernel in fido? >> >> If it's 3.14, then it seems unlikely that folks will be using 3.10.53. > > 3.14. > >>> I see no reason to keep it around and untested from now on. Community >>> resources for test are restrict so it will end untested plus the more >>> people relying on 3.14 the better as it is closer to mainline. >>> >> >> Can you clarify what you mean by 'it'? > > I mean it is easier to make backports of features/drivers when using > 3.14-based kernel than 3.10. So new users, when developing on top of > community, should use 3.14 for custom boards. 3rd parties are free to > choose to keep 3.10.53 or 3.14 in meta-fsl-arm-extra as their kernel, > depending on their schedule/convenience, as GPU is compatible. > That's true, but until the 3.14 kernel has some time in the wild, there is still the possibility of regression. >>> Someone one has any technical reason to keep it around? >>> >> >> If you're referring to 3.10.53 recipe for Freescale kernel, the >> tag/branch in git.freescale.com should be sufficient. > > Agreed. > >> Looking at Otavio's patch set, it appears that the changes include >> both kernel updates as well as some remaining packages (firmware-imx, >> imx-test, and such) that are named to reflect the kernel version >> numbering. >> >> https://lists.yoctoproject.org/pipermail/meta-freescale/2015-April/013274.html > > Yes. This is mostly due the EULA change as the components changes are > minimal, if any. > >> Having those old recipes around is probably more useful than the >> kernel, since I don't think they're all backed by proper git >> repositories. > > The recipes are. They are the current master ones so they are > available on Git history if needed. > >> How about just tagging/branching meta-fsl-* with a 3.10.53 name to >> make it easy to grab the set from before the switch? > > I am not a big fan of this. For tagging we've been following Yocto > Project schedule and we didn't use BSP version on those as we support > all SoCs, not just one. Branching is even worse as it will pass the > feel we are going to maintain it. > > FSL for example didn't send the 3.10.53-1.1.1 updates as 3.14.28-1.0.0 > is the current GA so if someone wants to use 3.10.53 I think FSL > layers is the best choice. > How about this as a compromise? - Add 3.14 as new components, then - remove 3.10.53 in an explicit patch set This might make it easier for those who want to stick with 3.10.53 for a while. Otherwise, you are forcing users to pin their down-stream repositories at versions that precede the introduction of 3.14 or go through a complete kernel re-test. Production users should probably not be on the master branch anyway, but I suspect that some folks are doing that. Regards, Eric