Bevy nursery: a path to upstreaming ecosystem crates #63
Conversation
|
Ah yes 1 comment: I don't think "pick the winner" is necessarily a drawback so long as those crates are integrated under a feature flag. If there's a "second winner" or even 2 strong crates to begin with, they likely each have strengths and weaknesses and are more suited for some use cases, so I don't think it's bad to have say 2 crates for audio that the user can choose from. |
There was a problem hiding this comment.
I really like this proposal because it provides a very clear path for upstreaming a crate, as well as explicit guidelines for those interested in doing so.
bevy_mod_picking was created based on @cart's prescient request to allow the picking API to be tested and mature in a parallel crate before integrating into the engine. With the nursery in place, it gives me a very clear path to contributing my work back to the engine, which is not currently the case. Instead of putting the work behind a flag, or in a PR that constantly needs to be rebased, this would allow for actual user testing like any other third party crate.
| 4. Will have a branch prepared for the newest release of Bevy before we release a new major version. | ||
|
|
||
| You can find these crates by looking for the special `Nursery` tag on [Bevy Assets](https://bevyengine.org/assets/), | ||
| or by browsing the [`bevyengine` organization](https://github.com/bevyengine)'s list of repositories. |
There was a problem hiding this comment.
If you like, you could also assign a nursery topic to the repositories themselves. A GitHub topic is like a label on a repository, and can be specified as a criteria in a search (if you wanted to, for example, link to a search displaying all the nursery repositories in the bevyengine org). For example, rust, game-engine, and 2d are topics on one of my own repositories in the screenshot below. You can add/edit topics by editing the About section of a repository.
There was a problem hiding this comment.
Neat, but I think this is probably redundant.
Co-authored-by: TimJentzsch <[email protected]>
Co-authored-by: TimJentzsch <[email protected]>
|
Feedback addressed :) The main point worth addressing explicitly at this point is "nursery crate owners get scoped merge rights". No override for controversial PRs any more; if that process needs accelerating we should address that separately. We could grant:
My personal feeling is that 2/3, possibly graduating to 4 is the right way to go :) In my experience, experimenting with authority over small areas has been a great model for both sides of the equation. |
Why should contributors going through the nursery process get merge rights, when PR contributors do not? I think we need a good answer to that question before deciding on what, if any, merge rights to grant. Does this imply that large enough PRs should be rejected, and told to go through the nursery process? What are the criteria for this threshold? |
I agree with this. The fact that someone wrote code does not qualify them to maintain it within the context of Bevy. That is a separate concern and should have its own process / criteria. Large PR vs Nursery are two paths that accomplish the same goal. They should be treated the same in this regard. I'm open to considering opening the doors to scoped merge rights (maybe via codeowners). But my vote is to remove things of this nature from this RFC and then have that conversation on its own time. |
There was a problem hiding this comment.
It's a great idea, I love it, but I have some questions, 3 related to nursery crates versioning, and another 4º:
4 - When a nursery crate will be removed/discontinued from bevy-nursery? In case of removing a nursery crate, it will be archived or "returned" to original author?
| 1. Live in the [`bevyengine` organization](https://github.com/bevyengine) on GitHub. | ||
| 2. Follow Bevy's standards for code quality and project management. | ||
| 3. Explicitly welcome community contributions to help get them ready for release. | ||
| 4. Will have a branch prepared for the newest release of Bevy before we release a new major version. |
There was a problem hiding this comment.
I have a few questions about this:
1- If some bevy repo PR introduce a breaking change into some nursery crate, there will be some defined process to detect and warn nursery crate maintainers? Like a custom CI on every nursery crate which will detect it?
2- What happens if at the end of the 3-month cycle, bevy is ready for a new release, but some nursery crates doesn't, either because of some complex breaking change or because maintainers didn't have time to update?
3- When releasing patch notes/migration guides/news, the changes on nursery crates will be included?
There was a problem hiding this comment.
I don't have any corrections to suggest, however I have some questions that I think are not answered in the RFC.
- What about more defined rules on branch structure? For example:
- Must the default branch be named
main? - Should one branch constantly track Bevy's
mainbranch? - If yes, what it should be? The default branch or a dedicated one?
- Must the default branch be named
- What happens to crates that are initially adopted by the nursery but at one point they become no longer the best solution for upstreaming (e.g. new better competitor, neglect, changes in Bevy vision)?
There was a problem hiding this comment.
I am very much in favour of this. Thanks a lot for moving this forward.
I am often very wary of adding new external plugins because of the mentioned drawbacks.
Having Bevy's official stamp of approval and guarantee that they are going to be maintained empowers users to try more functionality out.
RENDERED
Work done within the broader Bevy ecosystem is sometimes a good fit as part of the core engine.
These crates should live in a nursery owned by the Bevy org for a period of time,
where they can be polished and refined by the broader community,
before eventually being merged in completely.