I'd like to suggest - assuming it's not implied - that all aforementioned
PRs should preserve history to date, rather than just having a copy of the
files as they are at present.
Decent walkthrough using a subtree merge -
http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository/17864475#17864475
-Neil
On Tue, Jul 29, 2014 at 6:30 PM, Alex Crichton <a...@crichton.co> wrote:
> Now that cargo is starting to become a larger part of the Rust ecosystem
> it's time for some of the crates as part of the standard distribution to
> move out of the main rust repository. This movement has been planned for
> quite some time now, and it has only recently become possible with the
> advent of cargo.
>
> Starting today, we'd like to evolve crates not needed by rustc itself
> outside of the compiler wherever possible. This will reduce cycle time on
> development of these libraries, allow them to develop independently from
> rustc, and hopefully allow them to be more focused in their target goals.
>
> The process of moving crates out of the standard distribution will be an
> ongoing and evolving one. We currently have the benefit of being able to
> move the entire distribution forward in one atomic step with everything in
> one repository, but this quickly becomes infeasible with many repositories.
> We plan to implement any necessary infrastructure to ensure that the crates
> move out of the rust repository maintain the same level of quality they
> currently have.
>
> To this extent, the current process for moving a crate out of the standard
> distribution will be as follows:
>
> 1. A member of the core team will be contacted to create the repository
> `rust-lang/$foo`.
> 2. A PR will be made against `rust-lang/$foo` with the current copy of the
> code from `rust-lang/rust`. This PR will be expected to have the
> following source structure:
>
> * Cargo.toml - a manifest to build this repo as a cargo package
> * .travis.yml - configuration to run automated tests on travis. A
> sample can be found for hexfloat [1]
> * LICENSE-{MIT,APACHE} - copied over from rust-lang/rust
> * src/ - the same source structure as the folder in rust-lang/rust
>
> 3. A PR will be made against `rust-lang/rust` which will flag the relevant
> library as `#[deprecated]` with a message pointing at `rust-lang/$foo`
>
> In order to ensure that these repositories continue to stay up to date, we
> will have the following process in place:
>
> 1. Each repository will be hooked up to Travis CI and will be built each
> night once the new nightlies are available.
> 2. A status page [2] is provided to get a quick glance at the status of all
> officially supported repositories.
>
> The amount of infrastructure around keeping these repositories up to date
> will likely change over time, but this is the current starting point for
> automation.
>
> [1]: https://github.com/rust-lang/hexfloat/blob/master/.travis.yml
> [2]: http://buildbot.rust-lang.org/travis/travis.html
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
