activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <>
Subject Re: Git workflow for committers
Date Tue, 30 Jun 2015 14:26:34 GMT
On a slightly tangential note, the "commit-then-review" and "review-then-commit" terminology
isn't technically accurate when using Git.  It would need to be "push-then-review" or "review-then-push"
to reflect how Git actually works.


----- Original Message -----
From: "Justin Bertram" <>
Sent: Tuesday, June 30, 2015 8:27:45 AM
Subject: Re: Git workflow for committers

For what it's worth the Artemis Hacking Guide [1] has been updated based on this thread. In
essence, maintainers (i.e. committers) are free to push commits before peer-review, but are
encouraged to submit commits for peer-review when it makes sense. Non-maintainers obviously
have to submit their commits for review before they can be pushed and that process is outlined
as well [2].



----- Original Message -----
From: "Bruce Snyder" <>
Sent: Tuesday, June 30, 2015 8:15:42 AM
Subject: Re: Git workflow for committers

Hi Marc,

The ActiveMQ project has always operated on a CTR (commit-then-review)
basis. The only difference we seem to be experiencing is with Artemis and
it's more of a natural flow based on the use of pull requests vs. an
explicit plan to change to RTC (review-then-commit). I encourage you to
commit your changes to the repo (as you have already done) so that folks
can review them there. I also like the fact that you have sent a message to
the dev@ list describing your changes and encouraging other folks to review
your changes. I also really like the fact that you documented how to test
the scripts, nice work.

I still support documenting the workflows for our various repos simply
because I think it will help newbie contributors to understand how we work
as as group.


On Mon, Jun 29, 2015 at 1:49 PM, Marc Schöchlin <> wrote:

> Thanks Bruce,
> sorry for the delay - i was a really busy with a corporate project....
> I'm not really sure what i should do now to submit my changes because
> because i could not really recognize a broad consent on the discussion :-)
> My opinion is:
> Committing directly to the master master branch seems to be a a
> efficient/lean way to get things fixed or to make smaller enhancements
> with low effort.
> Extensive, complex, longterm and  dangerous changes should be managed
> and reviewed in feature branches (i.e. using Gitflow).
> From my point of view it would be a good idea to write a detailed wiki
> guide how to do this!
> The guide should describe in detail how to handle git correctly
> (configuration and detailed usage), the ticket system, requesting a
> review,.....
> Probably we just should start to write such a page (marked as draft) and
> request concrete improvements?
> Regards
> Marc
> Am 07.06.2015 um 21:10 schrieb Bruce Snyder:
> > New committer Marc Schöchlin has raised some questions about the git
> > workflow to use as he continues to work on the init scripts. This is a
> > perfect opportunity for all committers to discuss the workflow that we
> > recommend be used when working on ActiveMQ projects and I will document
> the
> > end result on the wiki in association with the 'How To Become a
> > Committer...' page.
> >
> > After many years of experience with git, I am a big fan of git flow (
> > but I don't
> > believe that is being used on ActiveMQ. So what is the general git
> workflow
> > that committers use today?
> >
> > Bruce
> >
> --
> GPG encryption available: 0x670DCBEC/
> (

perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'

ActiveMQ in Action:

View raw message