[rfc] Remove support for unsupported tool_chain_tags

[rfc] Remove support for unsupported tool_chain_tags

[Sean]

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

As discussed at the weekly tools meeting, I am proposing that all 
unsupported tool chains get removed from tools_def.template in the 
Basetools/Conf folder (edk2/tools_def.template at master · 
tianocore/edk2 (github.com) 
<https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template>). 
    The fact that VS2008 is still listed there is proof of a problem.  
Many of these old tool chains are not available and if found would not 
reliably work anyway (see dozens of emails on the list, most recent by 
rebecca).

The suggestion from the tools meeting discussions is that we should 
setup maintainers for each tool chain tag and any tool chain tag without 
a maintainer would then be removed.

Today the CI and PR system is testing the most recent versions of VS and 
GCC.  As of this email that tag is VS2019 and GCC5.  There has also been 
a desire to add clang (clangpdb tag) to the list of CI builds but it is 
currently only partially supported and needs some community effort.  The 
GCC5 tag might need more clarity as I know this supports many different 
versions so I am not sure how to correctly communicate what is the 
actual supported version.  Maybe the container discussion would help 
([CI] Use containers on Linux · Discussion #2732 · tianocore/edk2 
(github.com) <https://github.com/tianocore/edk2/discussions/2732>) and 
it could be N and N-1 on the latest container images?


Finally, the question is how to define a supported tool chain and what 
are the expectations for the "maintainer".  I would propose two things.

1. A category/tag created for the tool chain in the issue tracking 
system and the maintainer will be the default assigned owner for 
incoming bugs and is responsible for triage and resolution.

     a. If all maintainers resign the community would be notified and if 
no one came forward the toolchain would be dropped.

     b. If the tag had a high bug count and low resolution/response rate 
the toolchain maintainer role would be re-evaluated.

2. At defined points in the edk2 development process, each package is 
compiled in debug, release, and noopt for the toolchain for all 
supported architectures.   The report is made available.

     A. Suggested at minimum for each hard freeze stable tag point but 
could be CI, nightly, weekly, etc.

     B. Suggestion is this should somehow be automated for the CI system 
and tool chains supported.

3. Update maintainers.txt to indicate tool chain maintainers


Please use this email and/or tools meeting to discuss the proposal or 
becoming a toolchain maintainer.

RFC will be implemented after the may stable tag if no issues are raised.


Thanks

Sean










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

回复: [edk2-rfc] [rfc] Remove support for unsupported tool_chain_tags

[gaoliming]

Sean:
  After remove, the supported tool chain will have its maintainer. This is a good idea.

  For CLANG tool chain, CLANGPDB and CLANGDWARF supports IA32 and X64 arch only, they can run Windows/Linux/MacOs. CLANGPDB is to directly generate EFI image with PDB debug symbol, CLANGDWARF is to generate ELF image with DWARF debug symbol. CLANG35 is to support ARM and AARCH64 only. CLANG38 is to support IA32, X64, ARM and AARCH64 archs. It runs on Linux OS.

Steven: 
  Have you more information about CLANG tool chain?

Thanks
Liming
> -----邮件原件-----
> 发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Sean
> 发送时间: 2022年5月3日 7:24
> 收件人: rfc@edk2.groups.io; devel@edk2.groups.io
> 主题: [edk2-rfc] [rfc] Remove support for unsupported tool_chain_tags
> 
> As discussed at the weekly tools meeting, I am proposing that all
> unsupported tool chains get removed from tools_def.template in the
> Basetools/Conf folder (edk2/tools_def.template at master ·
> tianocore/edk2 (github.com)
> <https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.t
> emplate>).
>     The fact that VS2008 is still listed there is proof of a problem.
> Many of these old tool chains are not available and if found would not
> reliably work anyway (see dozens of emails on the list, most recent by
> rebecca).
> 
> The suggestion from the tools meeting discussions is that we should
> setup maintainers for each tool chain tag and any tool chain tag without
> a maintainer would then be removed.
> 
> Today the CI and PR system is testing the most recent versions of VS and
> GCC.  As of this email that tag is VS2019 and GCC5.  There has also been
> a desire to add clang (clangpdb tag) to the list of CI builds but it is
> currently only partially supported and needs some community effort.  The
> GCC5 tag might need more clarity as I know this supports many different
> versions so I am not sure how to correctly communicate what is the
> actual supported version.  Maybe the container discussion would help
> ([CI] Use containers on Linux · Discussion #2732 · tianocore/edk2
> (github.com) <https://github.com/tianocore/edk2/discussions/2732>) and
> it could be N and N-1 on the latest container images?
> 
> 
> Finally, the question is how to define a supported tool chain and what
> are the expectations for the "maintainer".  I would propose two things.
> 
> 1. A category/tag created for the tool chain in the issue tracking
> system and the maintainer will be the default assigned owner for
> incoming bugs and is responsible for triage and resolution.
> 
>      a. If all maintainers resign the community would be notified and if
> no one came forward the toolchain would be dropped.
> 
>      b. If the tag had a high bug count and low resolution/response rate
> the toolchain maintainer role would be re-evaluated.
> 
> 2. At defined points in the edk2 development process, each package is
> compiled in debug, release, and noopt for the toolchain for all
> supported architectures.   The report is made available.
> 
>      A. Suggested at minimum for each hard freeze stable tag point but
> could be CI, nightly, weekly, etc.
> 
>      B. Suggestion is this should somehow be automated for the CI system
> and tool chains supported.
> 
> 3. Update maintainers.txt to indicate tool chain maintainers
> 
> 
> Please use this email and/or tools meeting to discuss the proposal or
> becoming a toolchain maintainer.
> 
> RFC will be implemented after the may stable tag if no issues are raised.
> 
> 
> Thanks
> 
> Sean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: [edk2-devel] [rfc] Remove support for unsupported tool_chain_tags

[Andrew Fish]

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

I can sign up to maintain XCODE. 

I think Rebecca has been running test builds with XCODE. 

The XCODE5 names comes from the compiler flags needing to change for Xcode 5. Yes 2013 called and wants it compiler back. 

Thanks,

Andrew Fish

> On May 2, 2022, at 4:24 PM, Sean <spbrogan@outlook.com> wrote:
> 
> As discussed at the weekly tools meeting, I am proposing that all unsupported tool chains get removed from tools_def.template in the Basetools/Conf folder (edk2/tools_def.template at master · tianocore/edk2 (github.com) <https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.template>).    The fact that VS2008 is still listed there is proof of a problem.  Many of these old tool chains are not available and if found would not reliably work anyway (see dozens of emails on the list, most recent by rebecca).  
> 
> The suggestion from the tools meeting discussions is that we should setup maintainers for each tool chain tag and any tool chain tag without a maintainer would then be removed.  
> 
> Today the CI and PR system is testing the most recent versions of VS and GCC.  As of this email that tag is VS2019 and GCC5.  There has also been a desire to add clang (clangpdb tag) to the list of CI builds but it is currently only partially supported and needs some community effort.  The GCC5 tag might need more clarity as I know this supports many different versions so I am not sure how to correctly communicate what is the actual supported version.  Maybe the container discussion would help ([CI] Use containers on Linux · Discussion #2732 · tianocore/edk2 (github.com) <https://github.com/tianocore/edk2/discussions/2732>) and it could be N and N-1 on the latest container images?  
> 
> 
> 
> Finally, the question is how to define a supported tool chain and what are the expectations for the "maintainer".  I would propose two things. 
> 
> 1. A category/tag created for the tool chain in the issue tracking system and the maintainer will be the default assigned owner for incoming bugs and is responsible for triage and resolution.  
> 
>     a. If all maintainers resign the community would be notified and if no one came forward the toolchain would be dropped.  
> 
>     b. If the tag had a high bug count and low resolution/response rate the toolchain maintainer role would be re-evaluated.  
> 
> 2. At defined points in the edk2 development process, each package is compiled in debug, release, and noopt for the toolchain for all supported architectures.   The report is made available.  
> 
>     A. Suggested at minimum for each hard freeze stable tag point but could be CI, nightly, weekly, etc.  
> 
>     B. Suggestion is this should somehow be automated for the CI system and tool chains supported.  
> 
> 3. Update maintainers.txt to indicate tool chain maintainers
> 
> 
> 
> Please use this email and/or tools meeting to discuss the proposal or becoming a toolchain maintainer. 
> 
> RFC will be implemented after the may stable tag if no issues are raised.  
> 
> 
> 
> Thanks
> 
> Sean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


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

Re: [edk2-devel] [rfc] Remove support for unsupported tool_chain_tags

[Rebecca Cran]

Yes, I've been occasionally running builds on XCODE5. OvmfPkg currently 
fails with an unresolved symbol.

-- 
Rebecca Cran


On 5/4/22 19:58, Andrew Fish via groups.io wrote:
> I can sign up to maintain XCODE.
>
> I think Rebecca has been running test builds with XCODE.
>
> The XCODE5 names comes from the compiler flags needing to change for 
> Xcode 5. Yes 2013 called and wants it compiler back.
>
> Thanks,
>
> Andrew Fish
>
>> On May 2, 2022, at 4:24 PM, Sean <spbrogan@outlook.com> wrote:
>>
>> As discussed at the weekly tools meeting, I am proposing that all 
>> unsupported tool chains get removed from tools_def.template in the 
>> Basetools/Conf folder (edk2/tools_def.template at master · 
>> tianocore/edk2 (github.com) 
>> <https://secure-web.cisco.com/1jovXGUXzkmyOcPWsFfwVF8c1-cMBgjj4OtR63zneIutKSl9Z7QYpGf5iyGTRllboj490YDr72pe8YepZe0UbgLT5Uthzwh8hlBUHWgwmRZ-AKFK6C2RowZKRWXiT2NleScoTvUexYmn638gpSGGevs6ZOA5b34vH9bgkX2xs8OzXCCxA9AT2F0MgfICdKxKRtooc4I8oiKJMHNYBiE6aYxAtR_jNXiHyl1YhnsdLfJ3oLFKbEkHKkwjSXkMy2-AFcGNghLhBmh7sOGNz0JzOd4roY8m_oR9axO9N4t0a0bI99yphTTGsbITkzkVcrP2a_6w3qm_q_J6Myb2DMs_SrXNEV-c8RbHJ7Su2XPPO5Tw/https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FBaseTools%2FConf%2Ftools_def.template>). 
>> The fact that VS2008 is still listed there is proof of a problem.  
>> Many of these old tool chains are not available and if found would 
>> not reliably work anyway (see dozens of emails on the list, most 
>> recent by rebecca).
>>
>> The suggestion from the tools meeting discussions is that we should 
>> setup maintainers for each tool chain tag and any tool chain tag 
>> without a maintainer would then be removed.
>>
>> Today the CI and PR system is testing the most recent versions of VS 
>> and GCC.  As of this email that tag is VS2019 and GCC5.  There has 
>> also been a desire to add clang (clangpdb tag) to the list of CI 
>> builds but it is currently only partially supported and needs some 
>> community effort.  The GCC5 tag might need more clarity as I know 
>> this supports many different versions so I am not sure how to 
>> correctly communicate what is the actual supported version.  Maybe 
>> the container discussion would help ([CI] Use containers on Linux · 
>> Discussion #2732 · tianocore/edk2 (github.com) 
>> <https://secure-web.cisco.com/1zLgAR6B5-SUcmFO4cOtRjPqVRTx06z6LJSmrt5WtqNfQNyJVzKXu8oaGUNji2cHZh765CmOH1ciaYS_gAuDI8K-bkHIj7xQYSmWwdc2n3M4IrTkGFk3IBGjkjxrC1M04ypBMrE4wCvkFd-CGWpLLxUWCI7kUpK7kWLrm7iF0pYRpUmBQ6BeSvVpzqRJSc37hsBa9gMoieWTO6S6TBoSvX0WaPtw83Qq7BXKbOQ5qrooW6ekj__jBvNsv0TrBo1MZyf-F29zOVDJIoP7NisT_huUbWE78SeE_oxpfNXraj597TGKVtT1-VkUSC4FCAT4wxsNry4bHNhA71-HB_1brQIn9HaUeuW-hoX59F73uWkM/https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fdiscussions%2F2732>) 
>> and it could be N and N-1 on the latest container images?
>>
>>
>> Finally, the question is how to define a supported tool chain and 
>> what are the expectations for the "maintainer".  I would propose two 
>> things.
>>
>> 1. A category/tag created for the tool chain in the issue tracking 
>> system and the maintainer will be the default assigned owner for 
>> incoming bugs and is responsible for triage and resolution.
>>
>>     a. If all maintainers resign the community would be notified and 
>> if no one came forward the toolchain would be dropped.
>>
>>     b. If the tag had a high bug count and low resolution/response 
>> rate the toolchain maintainer role would be re-evaluated.
>>
>> 2. At defined points in the edk2 development process, each package is 
>> compiled in debug, release, and noopt for the toolchain for all 
>> supported architectures.   The report is made available.
>>
>>     A. Suggested at minimum for each hard freeze stable tag point but 
>> could be CI, nightly, weekly, etc.
>>
>>     B. Suggestion is this should somehow be automated for the CI 
>> system and tool chains supported.
>>
>> 3. Update maintainers.txt to indicate tool chain maintainers
>>
>>
>> Please use this email and/or tools meeting to discuss the proposal or 
>> becoming a toolchain maintainer.
>>
>> RFC will be implemented after the may stable tag if no issues are 
>> raised.
>>
>>
>> Thanks
>>
>> Sean
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> 

Re: [edk2-devel] [rfc] Remove support for unsupported tool_chain_tags

[Gerd Hoffmann]

  Hi,

> currently only partially supported and needs some community effort.  The
> GCC5 tag might need more clarity as I know this supports many different
> versions so I am not sure how to correctly communicate what is the actual
> supported version.

It's basically gcc 5 & newer.
I think all the GCC4x variants can be dropped by now.

take care,
  Gerd