Branch Naming

[tburghart]

Glossary

For the purposes of this discussion, I propose the following terminology:

• "project" refers to the GH organization (OpenRiak).
• "org" refers to a corporate-ish entity contributing to the project.
• "moniker" refers to a consistent label for an org, such as nhse, tiot, etc.
  • Each org has a unique moniker

Overview

Ultimately, a unified and consistently maintained Riak source base should be our goal, with consistent default branches.

We had talked about the "main" branches being develop for Riak-<next> and develop-?.? for version maintenance, which has the benefit of being mostly sort of in place, though with potential branch conflicts with the Basho repos.
Let's say Bet365 starts pushing their changes onto their develop* branches. We can say that those branches get pulled into our repos with a b365 prefix, but that still leaves a point of confusion for users facing two primary Riak source bases - which is the canonical develop?

User Harry decides "I'm gonna get me some Riak" and he reads on the internet that the Basho project is still around but there's also this OpenRiak project that looks lively. No problem, thinks Harry, I'll just set up two remotes in my git config (I may already be investing more sophistication in Harry than many users are likely to display). When he fetches from the basho and openriak remotes he has side-by-side develop branches that differ, which does he use?

While it's more work, I do think the above may make a strong case for a different namespace.
Where our "bleeding edge" is likely to be off amongst the various orgs' prefixed branches, we probably only need <something>-X.Y as the vetted releases, though we probably also need shared staging branches.

Tags will be another issue, but that doesn't affect branch naming so we can kick that can down the road for now.

Consensus

What I believe we've pretty much agreed on (and started implementing) is that for org frob:

• Team frob contains members who are associated with the frob org
• Branches frob-develop-?.? are the public representation of the frob org's Riak-?.? build.
• Branches frob/<whatever> are the frob org's work-in-progress that are, presumably, slated to be merged with frob-develop-?.?.
  • This pattern avoids clutter for others looking at repo branches in common GUI viewers that can collapse path-like branches.
  • WiP branches are always deleted once merged!
  • There are existing frob-<whatever> branches (as opposed to using the / delimiter) that can eventually die out from attrition; I do not propose renaming them.
• Team frob members are the only users who can push to branches with prefix frob- or frob/.
  • It will take time to get to this being enforced due to limited administrative options with GH free organizations. It will need to be honor-based until we can get rules in place.

Topics for Discussion

1. Is the above consensus accurate?
2. Should all repos have the same default branch?
3. What should the default branch be named?

[tburghart]

My personal 2¢:
I think that each repo's default branch should be openriak and version-specific release/maintenance branches should be openriak-?.?. This should avoid any namespace conflicts regardless of what we merge in.

[martinsumner]

If we have an openriak openriak-3.2 and openriak-3.4 what should be the rules regarding what each of those would represent, and the workflow for coordination. I think under basho develop was always the most up-to-date, but I haven't followed this over time, and I've tended to create -n.m branches when preparing stuff for new releases, so the non-versioned branch tends to lag not lead. so anything under nhse-develop is something that hasn't changed since 3.0, anything where nhse-develop-3.2 exists was changed for 3.2 and anything where nhse-develop-3.4 exists is because we have changes for 3.4.

What is the preferred alignment of branch naming and workflow going forward?

[martinsumner]

Forgot about an offline discussion.

Going forward we will have a default openriak branch where we maintain a rebar.lock (which will just be riak riak_test and basho_bench). Everywhere else we will have a default openriak-3.2. As we start on future releases, everything will point back to the previous branch (i.e. for openriak-3.4 it will point back at openriak-3.2) until we need to make changes specific to the future release, and then we will start an openriak-3.4 branch for that application (i.e. if the dialyzer/tests pass for the next release on the old branch, leave the deps reference at openriak-3.2).

If we want to patch the 3.2 release we will update openriak-3.2, and then raise a PR to update 3.4 if and only if there exists a openriak-3.4 branch already.

[martinsumner]

I'm happy to have openriak, or perhaps use an additional moniker (erlf say), that would represent the consensus viewpoint. Whether it be called openriak or erlf-develop, I think we're talking about the same thing.

What would be the starting point? Should we start with an existing organisations develop branch, or go back to the basho develop branch and submit PRs from that point. The latter is a lot of work for me - because I suspect nhse is several hundred commits ahead now of basho/develop ... but I guess this problem would be even bigger for Workday.

[tburghart]

I think the working nhse-develop* branches are the most viable starting point for the riak repo, since I believe your branches have the added benefit of actually building. Ours are incomplete and will be for a while.

Less sure about dependency repos, but may make sense to work from the top down and rely on rebar.lock until they're consistent.

[pjaclark]

That makes sense to me.

[martinsumner]

Riak Core now has an openriak-3.2 branch (default) and an openriak-3.4. All deps have an openriak-3.2 branch, and are setup for CI using Github Actions, with a CI badge on the readme.

The openriak-3.2 branch of riak_core still points at the old FeuerLabs exometer_core app, as we're using an old version in that release. For openriak-3.4 this is pointing instead at OpenRiak for exometer_core (and all deps thereof).