You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In RFC 1242, we described the original motivations for rust-lang-nursery and a process for accepting, iterating, and stabilising the crates within it. Some of the key goals of the nursery have been managing:
Governance
Maintenance
Quality
With respect to the standard library, the nursery has been serving a few purposes:
Flexibility for APIs outside of std
Somewhere to iterate and stabilise APIs over a long period (like net2 in RFC 1461)
Somewhere to stage APIs destined to be standard implementations in rust-lang alongside std (like regex in RFC 1620)
Somewhere to collect the APIs shaved off std before Rust 1.0
I think there are a few assumptions built in to the original processes surrounding the nursery (these might actually be incorrect!):
The way the Rust community collaborates is through RFCs
The maintenance of std will naturally extend to libraries in the nursery
All libraries in the nursery either belong in rust-lang as de-facto standards, or they should be deprecated
Over the last 3 years we've learned a lot about what maintenance in the nursery alongside std looks like, and how the Rust community can collaborate on API design outside of RFCs. The libz blitz has been an effective way to discuss motivations, evaluate design decisions and direct contributions to stabilising libraries. Nursery libraries themselves have followed different paths than the one outlined in RFC 1242:
uuid has been moved into a new external organisation and will stabilise there. So far I'm liking the GitHub organisation with liberal ownership + shepherd approach.
tempdir has been merged into the external tempfile crate and will stabilise in its next major version.
env_logger has been moved into a new external repository and will continue to develop there
bitflags has stabilised in the nursery.
log remains in the nursery and continues to develop there.
It would be great if we could revisit some of the goals and processes around the nursery with the experience and tools of the last few years and apply them in 2018.
The text was updated successfully, but these errors were encountered:
In RFC 1242, we described the original motivations for
rust-lang-nursery
and a process for accepting, iterating, and stabilising the crates within it. Some of the key goals of the nursery have been managing:With respect to the standard library, the nursery has been serving a few purposes:
std
net2
in RFC 1461)rust-lang
alongsidestd
(likeregex
in RFC 1620)std
before Rust1.0
I think there are a few assumptions built in to the original processes surrounding the nursery (these might actually be incorrect!):
std
will naturally extend to libraries in the nurseryrust-lang
as de-facto standards, or they should be deprecatedOver the last 3 years we've learned a lot about what maintenance in the nursery alongside
std
looks like, and how the Rust community can collaborate on API design outside of RFCs. The libz blitz has been an effective way to discuss motivations, evaluate design decisions and direct contributions to stabilising libraries. Nursery libraries themselves have followed different paths than the one outlined in RFC 1242:uuid
has been moved into a new external organisation and will stabilise there. So far I'm liking the GitHub organisation with liberal ownership + shepherd approach.tempdir
has been merged into the externaltempfile
crate and will stabilise in its next major version.env_logger
has been moved into a new external repository and will continue to develop therebitflags
has stabilised in the nursery.log
remains in the nursery and continues to develop there.It would be great if we could revisit some of the goals and processes around the nursery with the experience and tools of the last few years and apply them in 2018.
The text was updated successfully, but these errors were encountered: