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; Wed, 24 Apr 2019 02:57:34 -0700 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7DFEB285B3; Wed, 24 Apr 2019 09:57:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-123.rdu2.redhat.com [10.10.120.123]) by smtp.corp.redhat.com (Postfix) with ESMTP id D308660143; Wed, 24 Apr 2019 09:57:32 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOetlOWkjTogW2VkazItZGV2ZWxdIFJlcXVlc3Rpb24gZm9yIExUUyB2ZXJzaW9uIG9uIEVESzI=?= To: liyi 00215672 , "devel@edk2.groups.io" References: <31863.1555672260703193805@groups.io> From: "Laszlo Ersek" Message-ID: Date: Wed, 24 Apr 2019 11:57:31 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 24 Apr 2019 09:57:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/23/19 16:30, liyi 00215672 wrote: > Hi Laszlo, >=20 > Glad to get your detailed advices, it's useful for us. >=20 > We can give a label like "New feature" or "Bug fixed" to state the pat= ch or BZ, then the LTS maintainer can easy to distinguish whether put the= m(patch or BZ) into LTS version. I think no new label or keyword is needed in the TianoCore Bugzilla instance, as we track bugfixes vs. feature additions via different "Products": - "EDK2": bugs - "Tianocore Security Issues": security bugs - "Feature requests for Tianocore": feature requests Preferably, any non-trivial patch (set) should reference an associated BZ in the commit message(s), and so the classification would be connected to the patch(es) as well. Thanks Laszlo >=20 > Yes, I agree we can publish the LTS version once a year. >=20 > Thanks! >=20 > Yi =20 >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Laszlo Ersek [mailto:lersek@redhat.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=8823=E6=97=A5= 19:10 > =E6=94=B6=E4=BB=B6=E4=BA=BA: liyi 00215672 ; d= evel@edk2.groups.io > =E4=B8=BB=E9=A2=98: Re: [edk2-devel] Requestion for LTS version on EDK2 >=20 > On 04/19/19 13:11, liyi 00215672 wrote: >> Hi Laszlo, >> >> 1. If we could put some human resources into stable-branch(LTS), so=20 >> could you give us an rough=C2=A0assessment, how many people should we = put=20 >> them into that? :) >=20 > Honestly: no idea. >=20 > Maybe this could be estimated if all of the commits / BZs since the fir= st stable tag, edk2-stable201808, were now reviewed in retrospect, as to = whether each would be a candidate for backporting to a stable branch base= d on "edk2-stable201808". Alas, right now that means ~1500 commits, so no= t too easy either... >=20 > Perhaps you could dedicate one person ATM to monitor / investigate this= question. Monitor all of the new BZs and all of the patches posted to ed= k2-devel, and try to determine, working with the subject package maintain= ers, whether each issue is a bug (=3D not a new feature) and whether it a= ffects, say, "edk2-stable201903". If it does, then the patch is likely a = backport candidate. >=20 > If this person managed to actually backport these patches, let's say to= a personal stable branch for starters, and test them too, then in a few = months we might have evidence that the process works -- and then the cent= ral repo could grow such an official stable branch. >=20 > It's difficult to say how much extra time is needed, without researchin= g it first in practice. >=20 >> 2. If we make a stable-branch(LTS) into reality, we can invent some ru= les, likes one year(or two years) to release a LTS version, the LTS versi= on was only merged the bug-fixed. After the one or two years ,we=C2=A0wil= l release=C2=A0another new =C2=A0LTS version and the older one LTS we wou= ld maintain for 3-5 years. >=20 > I'd suggest starting small, and aiming at 1 year (tops) at first, for k= eeping a stable branch alive. >=20 > Thanks > Laszlo >=20