[zeromq-dev] Git workflow proposal

[Martin Lucina]

Pieter,

The workflow you have presented feels like an extremely formal workflow
geared towards a product produced by a small team of people. In your
workflow stable releases are tightly controlled and that a lot of effort
goes into making them "super-stable".

While all of the above is commendable I don't think it will scale all that
well with a community project such as ZeroMQ. To be honest, I also feel
that you're trying to get the "super-stable" maintained releases from the
community "for free" :-)

Some specific reservations:

 * "master" is the widely accepted standard for "what should go intro the
   next feature release". Let's not break that.

 * What you call "issue branches" are what everyone else calls "topic
   branches". Let's not break that either.

 * I'm in two minds about the "everything goes in the issue tracker"
   requirement. I find that in practice if a review workflow is enforced
   and if *all* (that includes Martin Sustrik :-)) contributors are taught
   to write meaningful commit messages then this requirement is somewhat
   redundant.

   At the very least, many projects have a policy that "trivially correct"
   patches (e.g. "Fix typo", "Add #ifdef HAVE_FOO for FooBarOS") go
   straight into "master".

   NOTE: I can see where you're coming from; delivering bug fixes to paying
   clients does *require* formal issue tracking. However, that is not the
   use case here.

   NOTE 2: As I said, I'm in two minds here, partly also because the Github
   issue tracker could use quite some improvement and I fear it'll be too
   clumsy to use in anger.

 * The separation of Maintainer/Committer roles does not work for me.
   Again, it's part of the "tightly controlled super-stable releases"
   policy. Also, implying that I'm a Maintainer suggests that I'm being
   paid to maintain super-stable releases for money, which I'm not.

   I would prefer a simpler model where:

    1) Martin Sustrik is SABDFL.

    2) There is a group of Committers. Committers are trusted not to step
    on anyone's toes and to follow the published Git workflows.

    3) Everyone else is welcome to submit patches to the mailing list as a
    Contributor.

    Graduation from 3) to 2) is based purely on merit.

 * Further, I've also read the gitworkflows(7) document (thanks to Peter
   Alexander for pointing to this) and I really like the workflow proposed
   there:

       ...As a given feature goes from experimental to stable, it also
       "graduates" between the corresponding branches of the software.
       git.git uses the following integration branches:

       * 'maint' tracks the commits that should go into the next
         "maintenance release", i.e., update of the last released stable
         version;

       * 'master' tracks the commits that should go into the next release;

       * 'next' is intended as a testing branch for topics being tested for
         stability for master.

       There is a fourth official branch that is used slightly differently:

       * pu (proposed updates) is an integration branch for things that are
         not quite ready for inclusion yet 

       Each of the four branches is usually a direct descendant of the one
       above it.

       Conceptually, the feature enters at an unstable branch (usually next
       or pu), and "graduates" to master for the next release once it is
       considered stable enough....

    I think this would work fine for ZeroMQ, provided that we actually
    write down a bunch of recipes for Committers to follow, something like:

    Q: I have a fix that needs to go in 'maint' and into 'master':

    (exact steps to achieve result follow)
    $ git merge ....

   The exact recipes are essential since none of us have that much
   experience with Git and it's quite easy to get things wrong. Also it
   means that any Committer can help on maintaining a stable release.

That's all for now, /me goes back into my cave writing code for
customers...

-mato