Requestion for LTS version on EDK2

Requestion for LTS version on EDK2

[liyi 00215672]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 346 bytes --]

Re: [edk2-devel] Requestion for LTS version on EDK2

[Laszlo Ersek]

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

Re: [edk2-devel] Requestion for LTS version on EDK2

[liyi 00215672]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

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? :)

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.

what's ur thoughts?

Thanks
Lee

[-- Attachment #2: Type: text/html, Size: 575 bytes --]

Re: [edk2-devel] Requestion for LTS version on EDK2

[Laszlo Ersek]

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

答复: [edk2-devel] Requestion for LTS version on EDK2

[liyi 00215672]

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.

	Yes, I agree we can publish the LTS version once a year.

	Thanks!

Yi  

-----邮件原件-----
发件人: Laszlo Ersek [mailto:lersek@redhat.com] 
发送时间: 2019年4月23日 19:10
收件人: liyi 00215672 <phoenix.liyi@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

Re: [edk2-devel] Requestion for LTS version on EDK2

[rebecca]

On 2019-04-18 17:26, Laszlo Ersek wrote:
>
> (1) Introduce stable *branches* to the development model. Those would be
> forked off at the stable tags (well, at some of them).


Would this be _re_ introducing stable branches? As explained in
https://github.com/tianocore/tianocore.github.io/wiki/UDK it seems the
project only recently moved from UDK<year> stable branches (at least, I
took them to be stable branches) to periodically tagging master with a
stable tag.


-- 
Rebecca Cran

答复: [edk2-devel] Requestion for LTS version on EDK2

[liyi 00215672]

It seems the UDK branch only merged some common and x86-specific patches , the non-x86 patches would not be merged into UDK branch.

So under my understanding ,the UDK is suitable only for x86 arch.

Thanks.

Lee

-----邮件原件-----
发件人: Rebecca Cran [mailto:rebecca@bluestop.org] 
发送时间: 2019年4月24日 1:53
收件人: devel@edk2.groups.io; lersek@redhat.com; liyi 00215672 <phoenix.liyi@huawei.com>
主题: Re: [edk2-devel] Requestion for LTS version on EDK2

On 2019-04-18 17:26, Laszlo Ersek wrote:
>
> (1) Introduce stable *branches* to the development model. Those would 
> be forked off at the stable tags (well, at some of them).


Would this be _re_ introducing stable branches? As explained in https://github.com/tianocore/tianocore.github.io/wiki/UDK it seems the project only recently moved from UDK<year> stable branches (at least, I took them to be stable branches) to periodically tagging master with a stable tag.


--
Rebecca Cran

Re: 答复: [edk2-devel] Requestion for LTS version on EDK2

[Laszlo Ersek]

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:lersek@redhat.com] 
> 发送时间: 2019年4月23日 19:10
> 收件人: liyi 00215672 <phoenix.liyi@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
> 

Re: [edk2-devel] Requestion for LTS version on EDK2

[Laszlo Ersek]

On 04/23/19 19:52, Rebecca Cran wrote:
> On 2019-04-18 17:26, Laszlo Ersek wrote:
>>
>> (1) Introduce stable *branches* to the development model. Those would be
>> forked off at the stable tags (well, at some of them).
> 
> 
> Would this be _re_ introducing stable branches?

Yes.

> As explained in
> https://github.com/tianocore/tianocore.github.io/wiki/UDK it seems the
> project only recently moved from UDK<year> stable branches (at least, I
> took them to be stable branches) to periodically tagging master with a
> stable tag.

UDK is conceptually identical to stable branches. The difference is that
all the resources that Intel used to sink into UDK, for evaluation,
backporting, testing, validation, etc, would now have to be offered by
the TianoCore community. (This would also allow for widening the scope,
of course, such as architecture support.)

Thanks
Laszlo