[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