Move to HdrHistogram org

[marshallpierce]

It's time! https://gitter.im/HdrHistogram/HdrHistogram?at=59c7d543c101bc4e3a01fb74

The naming convention isn't 100% consistent but it seems like HdrHistogram_Rust would be going with the flow.

[jonhoo]

I believe I would need to be added to the HdrHistogram org in order to transfer the repo. We'd also need to change Cargo.toml and .travis.yml to point to the new repository location.

[giltene]

Sorry for the huge lag. I hadn’t visited glitter in a while. Will try to be more on top of it in the future.

[jonhoo]

@giltene no worries at all!

[jonhoo]

One thing we should determine before we do the move is how we name the repository. I feel a little weird having the crate called hdrsample, but the repository HdrHistogramRust. Unfortunately, there is already a Rust crate called hdrhistogram (by @jsgf); it is pretty old, and uses FFI to expose a Rust API on top of the C implementation. Ideally we'd take over the hdrhistogram name (maybe @jsgf can help), but barring that, should we consider calling the repository under the HdrHistogram org something different?

[giltene]

Yeah, I’m surprised at Rust’s apparent choice around naming conventions for namespaces. This is a classic example where conflicts on the “obvious” naming of a package in a global and flat namespace is a really bad idea. I would imagine that wrapping C implementations first and later implementing a set of useful functionslity in pure Rust with more idiomatic forethought is a commonly observed pattern, and one that will tend to create this collision. The fact that the API will tend to change when this happens and break compatibility for existing code is a real problem.

Anyway, while you see if the crate named hdrhistogram can be relinquished or shared, deal with the backward compatibility questions and api name choices, we can use something like org_hdrhistogram or hdrhistogram_org (are dots allowed)? The annoying thing will be that once people start using that crate name, you’ll be stuck supporting it, and if you find a way to move to the flat hdrhistogram name you may have to publish the same implementation under two namespaces forever.

[giltene]

BTW, this is why I went through the (not so high) effort of registering the hdrhistogram.org domain name. To me, namespaces that use internet domain names as paths make the most sense, because they allow one to punt the “ownership” of the namespace to “the real world” and let others manage and police it. If non-prototype library publishers then start (in the first place) with an organization or project domain name that they had successfully acquired, the name remains protected from conflict by whatever rules govern the domain name hierarchy they chose. E.g. the Public Interest Registry manages conflict in the .org top level domain, so someone would have to convince them to yank control of org.hdrhistogram out of my hands if some legitimate unresolvable conflict emerged, or if I turn into a pumpkin without first bequeathing to someone else. Apache controls apache.org, so cassandra.apache.org is safe unless the Apache organization decides to mess it up. etc.

[jonhoo]

I think the intention in those cases is to transition the crate itself with a non-backwards-compatible major version number bump, which is also likely what we'll do with the current hdrhistogram crate. Rust's (or rather, Cargo's) semantic versioning means that no existing code will break, since existing version will remain live, and code won't be moved automatically to incompatible versions.

In any case, I've e-mailed the author, and we'll see what he says. I don't think there is that much of a rush to get this into the HdrHistogram org, so we should probably avoid the hassle of transitioning through an intermediate name. Dots are not allowed in crate names in Rust, so either of your proposed names would work, though I'd strongly prefer the non-_org version if we can get it.

The other annoying part will be that code that currently uses the hdrsample name will need to change, as I don't think Cargo supports crate "redirects". That said, existing code should keep working if we don't un-publish hdrsample, it just won't receive updates. By releasing a new minor update which deprecates the entire Histogram type, we should be able to signal the move pretty easily though.

[jonhoo]

I didn't get an answer to my e-mail, but I tried filing an issue over at jsgf/rust-hdrhistogram#1 since @jsgf has been active on GitHub recently.