On 04/23/19 16:30, liyi 00215672 wrote: > Hi Laszlo, > > Glad to get your detailed advices, it's useful for us. > > We can give a label like "New feature" or "Bug fixed" to state the > patch or BZ, then the LTS maintainer can easy to distinguish whether put > them(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 > > Yes, I agree we can publish the LTS version once a year. > > Thanks! > > Yi > > -----邮件原件----- > 发件人: Laszlo Ersek [mailto:ler...@redhat.com] > 发送时间: 2019年4月23日 19:10 > 收件人: liyi 00215672 <phoenix.l...@huawei.com>; devel@edk2.groups.io > 主题: Re: [edk2-devel] Requestion for LTS version on EDK2 > > On 04/19/19 13:11, liyi 00215672 wrote: >> Hi Laszlo, >> >> 1. If we could put some human resources into stable-branch(LTS), so >> could you give us an rough assessment, how many people should we put >> them into that? :) > > Honestly: no idea. > > Maybe this could be estimated if all of the commits / BZs since the first > stable tag, edk2-stable201808, were now reviewed in retrospect, as to whether > each would be a candidate for backporting to a stable branch based on > "edk2-stable201808". Alas, right now that means ~1500 commits, so not too > easy either... > > 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 > edk2-devel, and try to determine, working with the subject package > maintainers, whether each issue is a bug (= not a new feature) and whether it > affects, say, "edk2-stable201903". If it does, then the patch is likely a > backport candidate. > > 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 central repo > could grow such an official stable branch. > > It's difficult to say how much extra time is needed, without researching it > first in practice. > >> 2. If we make a stable-branch(LTS) into reality, we can invent some rules, >> likes one year(or two years) to release a LTS version, the LTS version was >> only merged the bug-fixed. After the one or two years ,we will release >> another new LTS version and the older one LTS we would maintain for 3-5 >> years. > > I'd suggest starting small, and aiming at 1 year (tops) at first, for keeping > a stable branch alive. > > Thanks > Laszlo > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39481): https://edk2.groups.io/g/devel/message/39481 Mute This Topic: https://groups.io/mt/31309500/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
