[?] Branching Mechanism

[dmth]

Please comment on / review the following proposal:

In order to differentiate between stable, development and maybe other branches, we should discuss a branching mechanism.

The mechanism:

• has to be simple
• has to be easy to understand for new contributors
• must allow a clear differentiation between revisions that are considered as "stable" and revisions that are considered as "WIP"
• must allow additional branching for package maintainers
• must allow the maintenance of "custom-code" in forked repositories
• MUST BE DOCUMENTED in the Developers guide

Similar to https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow and http://nvie.com/posts/a-successful-git-branching-model/ the mechanism I propose is:

• "Master" is the stable branch. Releases are done here. For convenience it could be called "Release" or "Stable". No new feature is merged into this branch directly. The only things allowed are Hotfixes and the "Release Candidate" Branch. Quality: All things are tested by multiple persons. The application should not crash.
  Log-Level: Warn
• A "Release Candidate" branch is used to make the code in development fit for production. This branch is stable enough for the package maintainers to test things and to create preliminary packages. The development branch is merged into this branch. If something is broken here, it will be fixed in a "bugfix branch" forked from this branch. This bugfix will be merged back into "RC" and "Development".
  Quality: All things are tested by multiple persons. The software is not expected to crash, but it will happen frequently.
  Log-Level: Info
• "Develop" is an integration branch, new features are integrated into this one.
  Quality: The Software is tested by at least one person. The software is expected to crash / fail / break frequently.
  Log-Level: Debug
• New Features are developed in additional feature branches. Once they are stable enough, features are merged into "Develop". Bugfixes to these features are done in the development branch, an if required, merged back into the feature branch.
  Quality: Software should be tested. The software is not expected to work.
  Log-Level: Debug

I've no idea who is tracking the issues, so I'm mentioning you directly. Do you have a proposal, or like to comment on this? @bernhardreiter @bernhard-herzog @gsiv @swilde

How does the proposed approach interact with forked repositories which contain code that will not go upstream?

[aaronkaplan]

Please also communicate that on the intelmq-dev list, if not already done so.

[aaronkaplan]

@bernhard-herzog @bernhardreiter @swilde @dmth : ping! Does that work for you guys?
If I get a GO from you, we will document it in the Developers guide and start doing it this way now.

[sebix]

If I get a GO from you, we will document it in the Developers guide and start doing it this way now.

What do you want to do exactly? I'd start with it once we have the feature-freeze/1.0 release preparations.

[aaronkaplan]

Well, the intevation folks should also feel OK with that proposed branching mechanism. So if they give us the GO, we can continue here.

[dmth]

@sebix and me talked about this. From my point of view it's a reasonable approach. I'll talk about this issue with team today. If there's no objection, we can start.

[aaronkaplan]

On 06 Oct 2016, at 10:31, Dustin Demuth notifications@github.com wrote:

@sebix and me talked about this. From my point of view it's a reasonable approach. I'll talk about this issue with team today. If there's no objection, we can start.

Perfect, thanks!

[bernhard-herzog]

The "Release Candidate" branch still seems a bit strange to me. The branching models described in the links (e.g. Gitflow on the Atlassian site) have new release branches forked off from the developement branch for each release. That seems more sensible to me.

Also, in the longer term, one stable branch will likely not be enough. Software that's more mature than IntelMQ at the moment may have multiple stable branches, e.g. one for the 1.x series of releases and one for the 2.x series of releases if both series are still supported by the development team. For IntelMQ that's far enough in the future, though, that we probably do not have to care about that now.

[dmth]

Who Is going to communicate this on the list?

[aaronkaplan]

On 07 Oct 2016, at 10:55, Dustin Demuth notifications@github.com wrote:

Who Is going to communicate this on the list?

I can do that but I'd first like to know if we are aligned.

[dmth]

From my point of view we are, if the RC-Branch is forked from Dev for each Release.

[aaronkaplan]

On 07 Oct 2016, at 11:25, Dustin Demuth notifications@github.com wrote:

From my point of view we are, if the RC-Branch is forked from Dev for each Release.

@sebix: OK for you?

[bernhard-herzog]

From my point of view we are, if the RC-Branch is forked from Dev for each Release.

The wording is not clear in this regard. In particular it says

The development branch is merged into this branch.

which sounds like it's a long-running branch, perhaps parallel to the develoment branch, into which the development branch is merged repeatedly.

A clearer description might be:

• For each release, a new "release candidate" branch is forked from the development branch
  in order to make the code in development fit for production. These branches is stable enough for
  the package maintainers to test things and to create preliminary packages. If something is broken,
  in a release candidate branch, it will be fixed in a "bugfix branch" forked from that branch. This
  bugfix will be merged back into the RC-branch and "Development".

[bernhardreiter]

Two remarks:

1. one of my worries is: who maintains all these "branches"? If we fail to have a good plan including people, it may be better to have less branches.
2. I am considering it strange to set the default log levels differently in different branches.
   It probably poses a little hurdle in maintance (if not done automatically). Also why shouldn't I run
   a high volume system on a development code? Overall we should have a good default for all
   branches.

[gulung]

Any problem to use this commonly accepted branching model?

[bernhardreiter]

@gulung image you've given does not explain some of the finer details how it is handled. Overall I believe it is too complicated for the current state of IntelMQ active contributors.

[ghost]

@gulung In principle I will be like that. master will be the current stable version, develop the current development branch. Everything else (hotfix and release branches) is only relevant for the core people.

I'll start this with the next development release (beta) or RC.