RFC: Merge naga into wgpu Repository

[cwfitzgerald]

Premise

Currently, despite how tightly linked naga and wgpu are, they live in different repositories, with different issue trackers, and test suites. There are a number of problems that arise from this, and we are considering merging naga into the wgpu repository. This can be done without losing history (we did it before merging wgpu-rs and wgpu-core into a single repo).

I have tried to put together a balanced pro/con list for doing this and want to reach out to the broader community for what people's opinions are.

Pros

• No more duplication of issues between the wgpu and naga repos.
• PRs changing both wgpu and naga no longer need two separate change sets which are synchronized with each other.
• Naga's PR tests will include all of wgpu's test suite, which can catch a lot more issues as they actually run the resultant shaders.
• Prevents naga and wgpu from falling out of sync with each other (doesn't happen a lot nowadays)
• Can leverage our existing codeowners system to keep PR reviews separated.

Cons

• People listening to wgpu notifications are now subjected to naga's issue/PR stream as well. (This is arguably a pro depending on your viewpoint)
• Naga does have unique, non-wgpu users, this will potentially make their process a bit more convoluted.
• Naga or wgpu specific issues will now be part of the combined list, making sorting slightly harder. This could be solved through triaging with labels.

wgpu/naga's maintainers currently expect the result of this to be merging repositories, but we are open to any and all opinions, so if you have a stake in this, definitely make your voice heard!

[nical]

I am very much in favor of this. A lot of friction came from having to juggle between the two repository while implementing the bgra8unorm-storage features which required changes in both repos.

I'll also add that the separation currently leads to different people changing naga's API and figuring out how to adapt wgpu to the changes.

It would also simplify the process of updating firefox and testing naga changes in firefox.

[Joeoc2001]

Naga does have unique, non-wgpu users, this will potentially make their process a bit more convoluted.

As someone with a few crates that use naga but not wgpu, as long as they stay as separate crates then I'm not sure what would change from my user perspective with this merge.

The only thing I'd want is for the versioning and release schedule for both to stay somewhat independent, to allow for the timely addition and release of Naga features which aren't utilised by WGPU.

[cwfitzgerald]

As someone with a few crates that use naga but not wgpu, as long as they stay as separate crates then I'm not sure what would change from my user perspective with this merge.

Nothing will change from the users perspective.

The only thing I'd want is for the versioning and release schedule for both to stay somewhat independent, to allow for the timely addition and release of Naga features which aren't utilised by WGPU.

Breaking changes for both naga and wgpu have always been released at the same time, patches are released on a crate-by-crate level whenever they need it, even within the wgpu workspace, so that will also continue.

[cwfitzgerald]

After seeing the community and maintainer response we are going to go ahead with this, next week after the wgpu 0.18 release.

We will make a point in the documentation of the new combined repo that naga is still a standalone project which has uses outside of wgpu.