Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Pedro Falcato 
On Wed, Nov 22, 2023 at 1:49 PM Leif Lindholm  wrote:
>
> On 2023-11-22 13:21, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2023 o 13:26, Leif Lindholm pisze:
> >> On 2023-11-22 11:11, Sami Mujawar wrote:
> >
> >>> [SAMI] The proposal above looks good to me. This may be slightly off
> >>> topic, but can we also enable edk2-platform upstream CI as well,
> >>> please? This would be helpful to catch issues much earlier. [/SAMI]
> >
> >> Yes, this is a problem we need to solve, but we don't have the time or
> >> resources to set up an upstream CI. What we've been thinking of
> >> is to let maintainers set up their own CI infrastructure and then
> >> have that perform any target-specific tasks and report back to
> >> upstream CI. It's been a few months since I last discussed this with
> >> Mike, but I think we were looking at
> >> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
> >> as a possible tool.
> >>
> >> This is probably not something we would like to tie into the edk2
> >> mergify workflow (it would add too much delay), but localised to
> >> edk2-platforms.
> >>
> >> Any help with implementing that would be most appreciated :)
> >
> > I can write CI jobs which would run tests for QEMU platforms:
> >
> > - virt/x86-64 (i440fx/q35)
> > - virt/aarch64
>
> These live in the main edk2 repo though, so are not part of the problem
> that needs solving.
>
> > - sbsa-ref/aarch64
> >
> > Sbsa-ref is something I am working on daily.
> >
> > If Github Actions is all what's needed then it can be done using
> > platform provided runners (no self-hosted needed).
>
> We need the self-hosted for the physical platforms, which are the main
> part of the problem. But setting something like this up for the
> edk2-platforms platforms we can test with qemu could be a good first step.

FWIW, QemuOpenBoardPkg and Ext4Pkg could also easily be tested with GitHub CI.
A problem with the current development model is that edk2-platforms
maintainers just push to master[1]. This is inherently CI-unfriendly.

I would have no problems maintaining my own repo and merging back
every once in a while, with a GitHub PR that would indeed go through
CI before merging. And this seems like the less painful solution,
compared to all the trouble EDK2 core has had with submitting changes,
etc, which I really do NOT want to deal with.

--
Pedro

[1] There's also the problem of knowing what edk2.git your
platform/feature package works with. Mine always aim for edk2.git
HEAD.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111622): https://edk2.groups.io/g/devel/message/111622
Mute This Topic: https://groups.io/mt/102746762/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Leif Lindholm 

On 2023-11-22 13:21, Marcin Juszkiewicz wrote:

W dniu 22.11.2023 o 13:26, Leif Lindholm pisze:

On 2023-11-22 11:11, Sami Mujawar wrote:


[SAMI] The proposal above looks good to me. This may be slightly off 
topic, but can we also enable edk2-platform upstream CI as well, 
please? This would be helpful to catch issues much earlier. [/SAMI]


Yes, this is a problem we need to solve, but we don't have the time or 
resources to set up an upstream CI. What we've been thinking of

is to let maintainers set up their own CI infrastructure and then
have that perform any target-specific tasks and report back to
upstream CI. It's been a few months since I last discussed this with
Mike, but I think we were looking at 
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

as a possible tool.

This is probably not something we would like to tie into the edk2 
mergify workflow (it would add too much delay), but localised to 
edk2-platforms.


Any help with implementing that would be most appreciated :)


I can write CI jobs which would run tests for QEMU platforms:

- virt/x86-64 (i440fx/q35)
- virt/aarch64


These live in the main edk2 repo though, so are not part of the problem 
that needs solving.



- sbsa-ref/aarch64

Sbsa-ref is something I am working on daily.

If Github Actions is all what's needed then it can be done using 
platform provided runners (no self-hosted needed).


We need the self-hosted for the physical platforms, which are the main 
part of the problem. But setting something like this up for the 
edk2-platforms platforms we can test with qemu could be a good first step.


/
Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111605): https://edk2.groups.io/g/devel/message/111605
Mute This Topic: https://groups.io/mt/102746762/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Marcin Juszkiewicz 

W dniu 22.11.2023 o 13:26, Leif Lindholm pisze:

On 2023-11-22 11:11, Sami Mujawar wrote:


[SAMI] The proposal above looks good to me. This may be slightly 
off topic, but can we also enable edk2-platform upstream CI as 
well, please? This would be helpful to catch issues much earlier. 
[/SAMI]


Yes, this is a problem we need to solve, but we don't have the time 
or resources to set up an upstream CI. What we've been thinking of

is to let maintainers set up their own CI infrastructure and then
have that perform any target-specific tasks and report back to
upstream CI. It's been a few months since I last discussed this with
Mike, but I think we were looking at 
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

as a possible tool.

This is probably not something we would like to tie into the edk2 
mergify workflow (it would add too much delay), but localised to 
edk2-platforms.


Any help with implementing that would be most appreciated :)


I can write CI jobs which would run tests for QEMU platforms:

- virt/x86-64 (i440fx/q35)
- virt/aarch64
- sbsa-ref/aarch64

Sbsa-ref is something I am working on daily.

If Github Actions is all what's needed then it can be done using 
platform provided runners (no self-hosted needed).



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111604): https://edk2.groups.io/g/devel/message/111604
Mute This Topic: https://groups.io/mt/102746762/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Leif Lindholm 

On 2023-11-22 11:11, Sami Mujawar wrote:

Hi Leif,

Please see my response inline marked [SAMI].


On the whole, tagging edk2-platforms at the same time as we tag the main
repo is unlikely to be beneficial. We'll need to introduce a freeze of
the platforms tree once the main repo stable tag is made and then wait
for reports/updates from maintainers.
And implement a deprecation/archiving process for platforms where this
does not happen in a timely fashion.
And I guess also tag the edk2-non-osi repo at the same time as the
platforms repo.


[SAMI] The proposal above looks good to me.
This may be slightly off topic, but can we also enable edk2-platform upstream 
CI as well, please? This would be helpful to catch issues much earlier.
There have been several instances where changes in edk2 repo have broken 
platforms in edk2-platforms and this has gone unnoticed until someone tried to 
build that platform.
I understand the proposal above requires maintainers to build and test the 
platforms once the platform freeze is announced.
However, I think having an upstream edk2-platforms CI may reduce some of the 
burden and last-minute rush for the maintainers.
Please let me know your thoughts.
[/SAMI]


TL;DR: not exactly.

Yes, this is a problem we need to solve, but we don't have the time or 
resources to set up an upstream CI.
What we've been thinking of is to let maintainers set up their own CI 
infrastructure and then have that perform any target-specific tasks and 
report back to upstream CI.
It's been a few months since I last discussed this with Mike, but I 
think we were looking at

https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
as a possible tool.

This is probably not something we would like to tie into the edk2 
mergify workflow (it would add too much delay), but localised to 
edk2-platforms.


Any help with implementing that would be most appreciated :)

/
Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111602): https://edk2.groups.io/g/devel/message/111602
Mute This Topic: https://groups.io/mt/102746762/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Sami Mujawar 
Hi Leif,

Please see my response inline marked [SAMI].

Regards,

Sami Mujawar

On 09/11/2023, 13:12, "disc...@edk2.groups.io  
on behalf of Leif Lindholm via groups.io" mailto:disc...@edk2.groups.io> on behalf of 
quic_llindhol=quicinc@groups.io > wrote:


-announce, +discuss


On 2023-11-09 12:02, Marcin Juszkiewicz wrote:
> W dniu 7.11.2023 o 01:59, gaoliming via groups.io pisze:
> 
>> Below is edk2-stable202311 tag planning Proposed Schedule
>>
>> Date (00:00:00 UTC-8) Description
>>
>> 2023-08-25 Beginning of development
>> 2023-11-06 Soft Feature Freeze
>> 2023-11-10 Hard Feature Freeze
>> 2023-11-24 Release
> 
> Can edk2-platforms and edk2-non-osi be tagged at same time as edk2? 
> There are projects outside which use both repositories to build firmware 
> for their use.
> 
> I was contacted with one of them as they had problem with SBSA Reference 
> Platform (sbsa-ref in QEMU, qemu-sbsa in TF-A, SbsaQemu in EDK2). Turned 
> out that their set of git repositories was far too much out of sync with 
> each other.
> 
> Having edk2-stable202311 tag in those 3 repositories show them exactly 
> which versions to use and make their life easier.


TL;DR: yes.


That is the long-term plan.
Perhaps approaching medium-term now.


But that requires pruning of platforms that are no longer actively 
maintained, and ongoing validation efforts on all platforms in 
edk2-platforms.


On the whole, tagging edk2-platforms at the same time as we tag the main 
repo is unlikely to be beneficial. We'll need to introduce a freeze of 
the platforms tree once the main repo stable tag is made and then wait 
for reports/updates from maintainers.
And implement a deprecation/archiving process for platforms where this 
does not happen in a timely fashion.
And I guess also tag the edk2-non-osi repo at the same time as the 
platforms repo.

[SAMI] The proposal above looks good to me. 
This may be slightly off topic, but can we also enable edk2-platform upstream 
CI as well, please? This would be helpful to catch issues much earlier. 
There have been several instances where changes in edk2 repo have broken 
platforms in edk2-platforms and this has gone unnoticed until someone tried to 
build that platform.
I understand the proposal above requires maintainers to build and test the 
platforms once the platform freeze is announced. 
However, I think having an upstream edk2-platforms CI may reduce some of the 
burden and last-minute rush for the maintainers.
Please let me know your thoughts.
[/SAMI] 

And there's not a whole lot of us to work on this. And currently we're 
focusing on migrating to the copilot^Wgithub PR system for 
submissions/review.


/
Leif
















-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111600): https://edk2.groups.io/g/devel/message/111600
Mute This Topic: https://groups.io/mt/102746762/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-09 Thread Leif Lindholm 

-announce, +discuss

On 2023-11-09 12:02, Marcin Juszkiewicz wrote:

W dniu 7.11.2023 o 01:59, gaoliming via groups.io pisze:


Below is edk2-stable202311 tag planning Proposed Schedule

Date (00:00:00 UTC-8) Description

2023-08-25 Beginning of development
2023-11-06 Soft Feature Freeze
2023-11-10 Hard Feature Freeze
2023-11-24 Release


Can edk2-platforms and edk2-non-osi be tagged at same time as edk2? 
There are projects outside which use both repositories to build firmware 
for their use.


I was contacted with one of them as they had problem with SBSA Reference 
Platform (sbsa-ref in QEMU, qemu-sbsa in TF-A, SbsaQemu in EDK2). Turned 
out that their set of git repositories was far too much out of sync with 
each other.


Having edk2-stable202311 tag in those 3 repositories show them exactly 
which versions to use and make their life easier.


TL;DR: yes.

That is the long-term plan.
Perhaps approaching medium-term now.

But that requires pruning of platforms that are no longer actively 
maintained, and ongoing validation efforts on all platforms in 
edk2-platforms.


On the whole, tagging edk2-platforms at the same time as we tag the main 
repo is unlikely to be beneficial. We'll need to introduce a freeze of 
the platforms tree once the main repo stable tag is made and then wait 
for reports/updates from maintainers.
And implement a deprecation/archiving process for platforms where this 
does not happen in a timely fashion.
And I guess also tag the edk2-non-osi repo at the same time as the 
platforms repo.


And there's not a whole lot of us to work on this. And currently we're 
focusing on migrating to the copilot^Wgithub PR system for 
submissions/review.


/
Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110977): https://edk2.groups.io/g/devel/message/110977
Mute This Topic: https://groups.io/mt/102434396/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-