bevyengine
Bevy nursery: a path to upstreaming ecosystem crates
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.
This RFC came about due to a discussion with @cart, @aevyrie and @alercah at RustConf :)
It presents an alternate approach to some of the goals in #52, to enable faster and more experimental iteration on large well-contained projects.
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.
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:
- No merge rights.
- Merge rights to directly relevant code.
- Merge rights to adjacent areas of the engine (e.g. all of audio).
- Full merge rights for non-controversial PRs.
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.
The main point worth addressing explicitly at this point is "nursery crate owners get scoped merge rights".
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?
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.
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.
After consideration, I agree with you @cart and @aevyrie. I've updated the RFC to match that position now :)