Repo Proposal: Detach our Basho forks

[tburghart]

Overview

The core OpenRiak repos are forked from those in the GitHub Basho project, which languish well behind anything that can be considered current versions.
The owners of the Basho project have shown little inclination to merge contributed changes - one of the primary motivations for this project.

Because of how GitHub calculates statistics, contributor stats to the OpenRiak repos are essentially useless, as contributions to forked repositories aren't counted until they're merged into a tracked branch in the standalone (not forked, i.e. Basho) repo.

This results in highly skewed repository contribution statistics AND makes it appear as though there is little activity in the OpenRiak repos, as their contribution stats are those of the Basho repos from which they're forked.

Proposal

I propose that we break the fork relationship with Basho repositories so that we get our own, accurate statistics.

Disadvantages

1. As described in the GitHub docs, we'd lose open issues and PRs on the repos (git commit metadata would be preserved).
2. I expect issue and PR numbering would reset to 1, with the potential for some confusion.
3. GitHub would no longer offer branch comparisons between the OpenRiak and Basho repositories.
4. GitHub may count common contributions (those that exist in both versions of a repository) twice in public statistics.

Mitigations

1. We'd probably want to keep the old, forked repos around, perhaps renamed with a -basho suffix and frozen to prevent new commits, for historical reference.
2. Overlapping issue/PR numbers are something we'd need to be cognizant off. We could burn off the overlapping numbers with dummies containing pointers to the originals in the historical copies - not sure if that's worth the effort.
3. Local developer tools offer comprehensive comparison capabilities when working clones are configured with multiple Git remotes, and in practice this is likely what most developers do anyway.
4. Due to the lack of recent activity in the Basho repositories, skewed historical statistics would likely be years old and not particularly relevant in GitHub's calculation of contributor activity.

Process

I believe the following steps should suffice to break the fork relationship, using myrepo as an example forked repository.
These are the steps from the GitHub docs, changed to rename instead of delete the original.

1. Locally, create a bare clone of myrepo.
2. In the OpenRiak project, rename myrepo to myrepo-basho.
3. In the OpenRiak project, create an empty myrepo.
4. Mirror-push the local myrepo clone repository back to the same remote URL.
5. Remove the local myrepo clone (you'll want to re-clone without the bare option to work on it).

Caveats

While I believe the process I've described should work, I haven't tried it yet.
I'm seeking guidance and/or warnings from someone who's done it (Kyorai/cuttlefish), will update with relevant feedback.

[martinsumner]

+1 for me.

In terms of contribution activity, almost all the activity (and planned future activity) is on riak, riak_kv, riak_test, riak_core and the two riak erlang clients. Do you have any thoughts on maybe leaving repos we intend to deprecate as basho forks, and splitting just for the things we expect to be part of the nucleus of riak going forward?

Related to this, there is the question of what to do with https://github.com/OpenRiak/kv_index_tictactree and https://github.com/OpenRiak/leveled. These are both forks from my personal repo.

For kv_index_tictactree, managing the process of updating both is just overhead, as I don't see anyone using it outside of Riak. For leveled things are a bit different as the martinsumner version has a relatively high number of forks/watches/stars on github, so there is more of a possibility that it does have a potential context outside of Riak.

[tburghart]

I was referring only to the Basho repos, which are essentially abandoned; your repos clearly aren't, so they don't give the impression of a dead project.

Yes, I'd constrain it to repos we want to keep going forward - the goal is to get current stats and signs of life, so there's no point for the repos we're not taking forward.

It must be noted that I don't know that we can rename and replace to keep the prior issue/pr history. The GH docs explicitly say to delete and replace the repo, and I know they keep redirected names so it may be that renaming won't sever the link and the new repo will effectively become a link to the old forked one. I'm going to experiment in a backwater project to see what happens.

In any event, we're going to lose chronological issue/pr tracking or at least make it difficult, and I see that as the biggest potential downside.

[michaelklishin]

@tburghart I haven't been following if OpenRiak's Cuttlefish has introduced any significant changes. The Kyorai fork did make some changes, mostly driven by RabbitMQ and VerneMQ needs. I'm afraid I do not see significant reasons for us to bring it back under OpenRiak. OpenRiak is welcome to use the Kyorai version, of course, and your feedback and contributions will be considered.

In other words, Cuttlefish has grown to be a standalone project and I am not sure why it should be folded into its original OpenRiak repo. Or at least what the current group of maintainers would gain from such a move. Not that we have much to lose either.

@lukebakken WDYT?

[tburghart]

I wasn't proposing bringing it under this project, was instead looking for any guidance on pain points when detaching your fork from the upstream - issue/pr number conflicts resulting from the numbering reset being a primary concern.

From the commit history it looks like Kyorai was initially a fork, then you detached it - is that the history, or did you create it detached initially?

[lukebakken]

Hi @tburghart, nice to see you in virtual space 😸

Neither @michaelklishin nor I had anything to do with the migration / fork / detach of the cuttlefish project. We became maintainers after that.

For what it's worth, the process you describe sounds good to me.

[michaelklishin]

@tburghart all I recall was that the detachment was intentional because Google and even GitHub search led folks to the Basho fork. We did it primarily to indicate that Cuttlefish is a standalone project that's reasonably actively maintained (given its general maturity).

Since then, a few contributors from other messaging/streaming Erlang-based tools have joint, whether with code contributions or discussions.

[tburghart]

So, I tried it, and renaming the original does work, the new repo doesn't end up pointing to the old one, and is detached.
@martinsumner any thoughts on what repo we want to start with here?

[martinsumner]

riak_core might be a good repo to start with. The only concern I have is where we have open and approved PRs with review comments in the PR - unapproved PRs with minimal discussion I'm happy to create again.

The main approved PR is OpenRiak/riak_kv#35, which I've left hanging in case there was any feedback on the discussion - https://github.com/orgs/OpenRiak/discussions/3. If you're happy, I'll merge the approved PRs by the New Year, and then then the rest can progress.

For open issues, do you think a new issue should be created for each one with a link to the issue in the renamed dep?

[martinsumner]

I've cleared out my outstanding PRs from the main repos. I will re-submit any required once the forks have been detached.