Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge-back to respective upstreams? #1

Closed
secure-sw-dev-bot opened this issue Jan 16, 2022 · 1 comment
Closed

Merge-back to respective upstreams? #1

secure-sw-dev-bot opened this issue Jan 16, 2022 · 1 comment
Labels
question Further information is requested

Comments

@secure-sw-dev-bot
Copy link

This issue was copied from checkedc/checkedc-clang#1


First of all, thanks a lot for putting this out in the public-domain.

I have a few questions, not sure if this is the best place to ask, but here I go:

A lot more users will directly benefit form this if this is provided as a package through distro-repositories for major OS distributions. So my questions are around how the teams sees this going forward:

  • Is the team working with upstream to merge changes back to clang/llvm codebases? If so, what release is being targeted/what timeline?
  • If merge-back is not on the cards, what is the long-term plan wrt packaging for various OS distro-flavors? Is the aim to make it available as separate packages on major distros (eg. Debian)?
  • If the plan is to have a separate distribution in the long-term, what does this mean for work that happens on Clang/LLVM upstream? Will patches from Clang/LLVM be merged back from time to time? How will the releases be planned?
@secure-sw-dev-bot secure-sw-dev-bot added the question Further information is requested label Jan 16, 2022
@secure-sw-dev-bot
Copy link
Author

Comment from @dtarditi:

Yes, we would like to push this upstream to LLVM/clang. It is pretty early in the compiler implementation, so we are not ready to do that yet. As we make progress, we plan to have discussions with the clang team about doing that. clang has a written policy about taking language extensions back. The bar is reasonably high - you need to have a substantial user community and a proposal before the standards body for the language. As we make progress with the compiler implementation, we'll be in a good position to have a discussions with the clang folks about possibly taking this back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant