I guess the case for using the Git Hub workflow largely boils down to
whether people want to use the Git Hub tooling, as the tooling is
largely based on the work flow.
I am sure there are lots of work flows that would work just fine. If
developers are just going to side step the tooling and work directly
against git repos then perhaps the Git Hub work flow is not the way to
go. The Artemis steps outlined in the guide Justin mentioned were
largely put in place to allow good use of the Git Hub tooling (whilst
working with the read only Apache mirrors).
As is probably obvious my personal preference is to us the tooling
provided by Git Hub, I feel it has worked well for Artemis and for many
other projects (both big and small) I have contributed to in the past.
I'd also imagine that the work flow is familiar to many other developers
(given the popularity of Git Hub) and using it may lower the barrier to
entry for new committers.
On 08/06/15 16:44, Thiago Kronig wrote:
Regarding git flow, I think it inserts layers of indirection only useful to
projects with some degree of concurrent development. At the current pace of
Artemis, having a master as a development branch and cooking up
issues/fixes on feature-branches should suffice.
Github flow: always branch from master, propose a PR, after peer review, if
it is minor, merge it to master, if it is not, either bump the version up
and merge it or reserve it for a future release. PRs can be made of
multiple commits if it facilitates our understanding, and should be merged
with --no-ff, to avoid rebase mistakes.
On Mon, Jun 8, 2015 at 10:59 AM Martyn Taylor <[email protected]> wrote:
Similar to other comments here.
My preference to use Git Hub work flow for all. A consistent work flow
across board keeps everyone on the same page. I also feel that peer
reviews are important part of the work flow. It helps prevent mistakes
and keeps the code base in good shape.
On 08/06/15 14:41, Daniel Kulp wrote:
On Jun 8, 2015, at 9:35 AM, Justin Bertram <[email protected]> wrote:
We recently published a Hacking Guide that outlines the typical
development cycle:
https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/code.md#typical-development-cycle
Improvements are certainly welcome.
I think this is ok for workflow for non-committers. Nice to have that
documented. Committers should not have to go through github.
In particular: step 4 can just be push your branch to a new branch at
Apache. There isn’t a need for github for that
Step 5: if you push to Apache in step 4, all the commits would be on
the Apache commits list and would be fine for discussion from there.
Step 7: if you are a committer, just push it to master. There is no
need for the pull requests from github.
Dan
Justin
P.S. I already sent a PR to get the references to the old JIRA repo
(i.e. ACTIVEMQ6) updated to the new one (i.e. ARTEMIS).
----- Original Message -----
From: "Bruce Snyder" <[email protected]>
To: [email protected]
Sent: Sunday, June 7, 2015 2:10:14 PM
Subject: Git workflow for committers
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 (
http://nvie.com/posts/a-successful-git-branching-model/) but I don't
believe that is being used on ActiveMQ. So what is the general git
workflow
that committers use today?
Bruce
--
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: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
