Repository navigation
Project organisation #578
Description
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?).
Activity
dhardy commentedon Aug 3, 2018
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:
Ugly using both _ and - in the names. Unless we use rust-random/xorshift for the project/repo names, despite keeping
rand_xorshiftfor the crate name?newpavlov commentedon Aug 3, 2018
Wasn't it discussed to use
*-rngas a naming convention for RNG implementation crates?UPD: I can transfer ownership of
isaac-rngif you want.dhardy commentedon Aug 3, 2018
Was it? That's not the notation we've been using in #431, but I guess we could. It's not consistent with
rand_corethough, or the newly proposedrand_stat(see #290).newpavlov commentedon Aug 3, 2018
IIRC proposal was to use
*-rngwas for RNG implementations which depend only onrand_coreandrand-*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 discussedRngCore.dhardy commentedon Aug 4, 2018
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_coreis now stuck (my fault for registering it too early).It sounds like the
-vs_thing won't matter much though: rust-lang/cargo#2775dhardy commentedon Aug 4, 2018
Okay, I can go ahead and transfer this repo to https://github.com/rust-random/rand but:
On the topic of new repos, which is preferable:
rust-random/rand,rust-random/rand_core,rust-random/rand_xorshift(rand_xorshiftcrate), ...rust-random/rand,rust-random/rand_core,rust-random/xorshift-rng(xorshift-rngcrate), ...rust-random/rand,rust-random/core,rust-random/xorshift(either above name), ...vks commentedon Aug 4, 2018
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 therand_prefix (1.), because it is consistent withrand_coreand it suggests that the crates are official parts of the Rand project.newpavlov commentedon Aug 9, 2018
Personally I don't like having too many repositories, and would prefer having something like this:
rust-random/randforrand,rand_core(also mayberand_statand others if they will be sufficiently small)rust-random/rngsfor RNG cratesI think it will be much easier to maintain and get into.
dhardy commentedon Aug 10, 2018
@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 commentedon Aug 10, 2018
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
devbranch after migration to therust-randomorg? Personally for our scale I don't see much profit in comparison to simply havingmasteras de-facto dev-branch + tags for marking release commits.About naming: I think having
rand_osfor OS RNG will be quite strange, andrand_os_rngwill be even worse.dhardy commentedon Aug 10, 2018
I don't want a
devbranch; usingmasteras 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.2branch forrand_core) or somehow build astablebranch containing the latest stable release for each crate (probably not practical).newpavlov commentedon Aug 10, 2018
If you need to backport some changes or fix something while
masteralready 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 developingdigest v0.8, which I've hoped to finish relatively fast, but development has stalled, thus I had to create branchbackport_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 commentedon Aug 10, 2018
We've actually released quite a few patch versions after
masterbecame the next version dev branch, but usually by implementing fixes on the old branch first then merging intomaster.dhardy commentedon Aug 10, 2018
Oh, and the transfer is now done!
dhardy commentedon Aug 13, 2018
Okay, lets go with @newpavlov's suggestion to call the repo
rngs(or we could be more specific and useprngs, but the former is probably better).rand_xorshiftandrand_isaacafter abovedhardy commentedon Oct 16, 2018
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.