[zeromq-dev] Git workflow proposal

[Pieter Hintjens]

Mato,

Thanks for the comments.

Ignoring name differences ('unstable' vs 'next'), what I gather from
your email is:

1. No maintainers, just SABDFL plus committers, selected by merit
2. No multiple branches for releases, just a single 'maint'
3. Option to commit changes directly to master without review
4. We need a better issue tracker than github
5. We do not need a tight link between issue tracking and topic branches.

Your original requirements to me were "every change should be
reviewed" (before it's applied to master, I assumed) and "no
exceptions, this applies to everyone".

My comments on your comments:

1. A group of committers and no 'maintainers' (in this workflow) seems perfect.
2. Package/release maintainers can work independently and outside this
workflow, on their own repositories.
3. "Selection by merit" is preaching to the choir. Read my blog
posting from yesterday.
4. A single maintenance branch seems fine.  But sooner or later we'll
need more than one IMO.
5. If you're happy reviewing commits AFTER they're applied to master,
we can allow direct commit to master for simple changes.
6. I'd agree that we need a better issue tracker.  Not Jira, pretty please.
7. I'd really like (even for my own work) a tight link between issues
and topic branches.

There is a really important thing you're missing, which is design by
contract.  We miss this in 0MQ.  The reason for tying changes into
documented issues is to 'encourage' people who shoot first and explain
later to instead document first, then shoot, then confirm the critter
is really dead.

Note that the workflow I wrote down came from Wikidot, where it turned
a "anyone commits anything" chaos into a really clean (and not heavy)
process.  It's not about paying clients but about having a predictable
workflow that others can rely on.  I.e. you know what is going on, you
know what happened, and you know where to discuss it.

-Pieter