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@...> 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

On May 2, 2022, at 4:24 PM, Sean <spbrogan@...> 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