From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 18 Apr 2019 16:26:48 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 56FF8C02490F; Thu, 18 Apr 2019 23:26:48 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-179.rdu2.redhat.com [10.10.120.179]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9C5CE19C79; Thu, 18 Apr 2019 23:26:47 +0000 (UTC) Subject: Re: [edk2-devel] Requestion for LTS version on EDK2 To: devel@edk2.groups.io, phoenix.liyi@Huawei.com References: <13372.1555571870534300928@groups.io> From: "Laszlo Ersek" Message-ID: Date: Fri, 19 Apr 2019 01:26:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <13372.1555571870534300928@groups.io> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 18 Apr 2019 23:26:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/18/19 09:17, liyi 00215672 wrote: > Hi Guys, > Backgroud: If we choose one stable-tag as our own UEFI codebase, however after 3 years, there are so many new features(but we don't need) will be added into EDK2 main tree. > > Requestion: Could EDK2 community plan or maintain "LTS version" concept like Linux? On LTS version , we only make bug fix or security-related. This question can be approached in two ways. (1) Introduce stable *branches* to the development model. Those would be forked off at the stable tags (well, at some of them). Stable branches are pretty usual with other open source projects. Unfortunately, they need a bunch of additional work. So when anyone asks, "can you maintain a stable branch for us", the default answer is to ask back, "can you contribute human resources for stable branch maintenance". :) In addition, releases (tags) on stable branches need heavier process and heavier testing. Regressions on stable branches are really bad. The community needs to invent (or, well, "steal") rules for what qualifies for stable branches and what doesn't. (2) I'm a very strong believer in one grand unified git history for *everything* in edk2. (Personally I even think that edk2-platforms should exist within edk2, but I digress.) The reason is very simple: if you want to ignore progress on some modules, you can easily do that [*] even if the git repo is comprehensive. However, if you split things to separate repos, then *reconstructing* a comprehensive history (and navigating / bisect it for bug analysis) is basically *impossible*. Put differently, it is easy to throw away information if you don't need it, but you can't conjure it up from thin air when you do need it. [*] If you decide you don't want module Foo to advance beyond commit Bar for you, then you can simply check out the Foo module into your git working directory (and index) at commit Bar, just before you launch your build: git checkout Bar -- Path/To/Module/Foo You can repeat this command arbitrarily many times, with different commits for different modules, before you launch the build. Thanks Laszlo