[zeromq-dev] When unreliability is desired

Pieter Hintjens ph at imatix.com
Sun Dec 8 22:38:09 CET 2013


On Sun, Dec 8, 2013 at 10:01 PM,  <lindleyf at gmail.com> wrote:

> I'll recreate the issue there.

Sure, we're going to have overlapping trackers for a while (different
ranges of issue numbers) so there's no problem.

> I can see how C4 could be considered more democratic and less authoritarian than git flow since anyone can fork for stabilization (equivalent to creating a release branch in git flow). I also see how it could be less error-prone to create a feature fork rather than a feature branch. But fundamentally I don't see any significant differences in the two processes....both go from features/bugfixes, to a probably-good-but-unblessed state, to a stabilization (bugfix and testing only) state, to a released state.

Perhaps we can catch up this thread later when you've used C4 for a
while and seen how it works. We for sure use stabilization forks as
gitflow uses branches, but that's only a small part of C4. The rest is
about reducing barriers to learning, as a group, in a number of small
but specific ways. The code emerges as we learn, and is our primary
tool for learning more, rather than being the one-way product of
educated minds.

-Pieter



More information about the zeromq-dev mailing list