Project organisation

[dhardy]

Hello all (but especially @pitdicker, @vks, @sicking, @TheIronBorn, @newpavlov),

since it seems we are going in the direction of having several sub-crates (rand_core is already released, rand_isaac and rand_xorshift are awaiting release, rand_stat is being planned and a few more PRNG crates are likely), I've decided to open a new GitHub organisation, rust-random, allowing multiple repositories and easier crate ownership on crates.io. I have contacted @alexcrichton who sees no reason against this.

The plan is to move this repo over there (once you've all had a chance to see this, and hopefully not complain too much 😉 ).

Sub-projects can potentially start within the main Rand repo, but should be moved to a new repository relatively soon (by first release) so that their history can be tracked independently. This should make checking changes to individual crates easier, and especially facilitate PRs (which often land on master, though that may not be the branch for the next release of some sub-crate currently).

Currently I am the only admin, but I (tried to?) invite @pitdicker, and can potentially add one or two members of the Mozilla team (@alexcrichton?).

[dhardy]

First up, I should be clear that nothing is holding us to this plan should we need to change things, though I see there's already a few thumbs-up!

I just created two repos:

• https://github.com/rust-random/rand_xorshift
• https://github.com/rust-random/rand_isaac

Ugly using both _ and - in the names. Unless we use rust-random/xorshift for the project/repo names, despite keeping rand_xorshift for the crate name?

[newpavlov]

Wasn't it discussed to use *-rng as a naming convention for RNG implementation crates?

UPD: I can transfer ownership of isaac-rng if you want.

[dhardy]

Was it? That's not the notation we've been using in #431, but I guess we could. It's not consistent with rand_core though, or the newly proposed rand_stat (see #290).

[newpavlov]

IIRC proposal was to use *-rng was for RNG implementations which depend only on rand_core and rand-* for higher level libraries like various distributions which will be generic over RNGs. I can't find exact links, but I think it was in one of the early issues which discussed RngCore.

[dhardy]

It doesn't really matter now what the proposal was; we can still go either way. Consistent naming would be nice; unfortunately it seems rand_core is now stuck (my fault for registering it too early).

It sounds like the - vs _ thing won't matter much though: rust-lang/cargo#2775

[dhardy]

Okay, I can go ahead and transfer this repo to https://github.com/rust-random/rand but:

• Should we publicise this somehow? Perhaps unnecessary.
• GitHub will redirect links see here, so there is no major issue, but we need to update the READMEs
• CI will need to be updated
• Anything else?

---

On the topic of new repos, which is preferable:

1. rust-random/rand, rust-random/rand_core, rust-random/rand_xorshift (rand_xorshift crate), ...
2. rust-random/rand, rust-random/rand_core, rust-random/xorshift-rng (xorshift-rng crate), ...
3. rust-random/rand, rust-random/core, rust-random/xorshift (either above name), ...
4. other?

[vks]

On the topic of new repos, which is preferable:

I would probably mirror rust-num, they use the same name for the repo as for the crates. This corresponds to 1. or 2. I prefer the rand_ prefix (1.), because it is consistent with rand_core and it suggests that the crates are official parts of the Rand project.

[newpavlov]

Personally I don't like having too many repositories, and would prefer having something like this:

• rust-random/rand for rand, rand_core (also maybe rand_stat and others if they will be sufficiently small)
• rust-random/rngs for RNG crates

I think it will be much easier to maintain and get into.

[dhardy]

@newpavlov perhaps you can provide perspective on the version control — but having multiple crates in a single repo implies more confusion if separate stable and development branches are used (as with the 0.5 and master branches now). You find that combining multiple crates in a repo is the easier option in spite of that?

[newpavlov]

I think that this model (one repo for group of crates) works quite well in the case of RustCrypto. I don't think that amount of confusion due to the existence of dev branch depends that much on whether we have single or multi crate repo. Plus what is your motivation for a separate dev branch after migration to the rust-random org? Personally for our scale I don't see much profit in comparison to simply having master as de-facto dev-branch + tags for marking release commits.

About naming: I think having rand_os for OS RNG will be quite strange, and rand_os_rng will be even worse.

[dhardy]

I don't want a dev branch; using master as the "dev" branch seems to cause less confusion. But we do use a 0.5 branch currently for patches to the stable series — we would either need several such branches (e.g. core_0.2 branch for rand_core) or somehow build a stable branch containing the latest stable release for each crate (probably not practical).

[newpavlov]

If you need to backport some changes or fix something while master already contains breaking changes (hopefully such situations will be quite rare), you always can return to the tagged commit and branch from it. For example I had to do this with RustCrypto/traits repository, I started developing digest v0.8, which I've hoped to finish relatively fast, but development has stalled, thus I had to create branch backport_digest-v0.7. I agree it's not the nicest thing to have, but it's workable. Yes, in multi-crate repo you may end up having several branches for different crates, but I think that net-sum of confusion will be smaller compared to the one crate per repo approach.

[dhardy]

We've actually released quite a few patch versions after master became the next version dev branch, but usually by implementing fixes on the old branch first then merging into master.

[dhardy]

Oh, and the transfer is now done!

[dhardy]

Okay, lets go with @newpavlov's suggestion to call the repo rngs (or we could be more specific and use prngs, but the former is probably better).

• Update paths Update paths due to relocation #587
• Update authors description instead of "The Rust Project Developers"? See removal of AUTHORS.txt and update of COPYRIGHT. See also COPYRIGHT file missing #468.
• Move rand_xorshift and rand_isaac after above

[dhardy]

We actually decided to reverse the decision to use a new repo for RNGs in #624, at least for any algorithms still in use by the main Rand lib.