Pieter,
p...@imatix.com said:
> Thanks for the comments.
>
> Ignoring name differences ('unstable' vs 'next'), what I gather from
> your email is:
Not quite. 'master' == 'reviewed, destined for next release'. 'next' ==
'under review, may be broken but builds, may or may not hit master (stuff
can be reverted from next)'.
Suggest you read the full gitworkflow(7).
> 1. No maintainers, just SABDFL plus committers, selected by merit
Ack.
> 2. No multiple branches for releases, just a single 'maint'
See below under 4).
> 3. Option to commit changes directly to master without review
> 4. We need a better issue tracker than github
Ack. We can probably make do with 4) the Github issue tracker for a while
(or encourage them to improve it!).
> 5. We do not need a tight link between issue tracking and topic branches.
Maybe. See below under 7).
> 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".
See below under 5) :-)
> 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.
That's not how gitworkflow(7) works. I did not want to repeat the content
of that document, but the idea is you have a 'maint-X.Y.Z' if you need to
maintain multiple maintenance releases. I suggest you read the entire
document yourself.
> 5. If you're happy reviewing commits AFTER they're applied to master,
> we can allow direct commit to master for simple changes.
The point here is that a Committer is trusted to make a judgement call.
Obviously even simple changes from a Contributor must go through a
Committer and get at least cursory review. Also it lowers the barrier for
Contributors with simple changes (Do I really need to create an issue to
fix a typo? I think not?).
> 6. I'd agree that we need a better issue tracker. Not Jira, pretty please.
Not Wikidot, pretty please. As I say above, maybe we should talk to the
Github people about improvements to the issue tracker. Most of what I have
in mind is fairly minor stuff, I think.
> 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.
I don't have a problem with that but knowing the way Martin Sustrik works
he might :-)
Also the nature of some work is experimental and it will gradually evolve.
That's not saying that the experimental work shouldn't be documented once
it hits master but some people (Martin again) have a different modus
operandi than "Document the contract first".
Also, my point about commit messages is that a Contributor can choose to
either open an issue or document their work in the commit message. The two
approaches seem of equal merit.
-mato
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
