+1 to removing the distinction. Master is the default branch in a lot of
projects and I would argue that is the common expectation. It sounds
like we can do gitflow without a separate develop branch (or at least it
isn't too painful) so doing what new people tend to expect is a good thing.
rb
On 08/13/2015 12:55 PM, Mark Payne wrote:
I think the issue here is less about gitflow being "hard" and more about it
being confusing.
We have had numerous people write to the dev list about why the thing that they
checked out
doesn't have what they expect.
Even being very experience with NiFi, I've cloned the repo a couple of times to
new VM's
and forgotten to checkout develop before proceeding.
I think that gitflow has its merits, but like any other avenue we go down, it's
important to weigh
pros against cons. Frankly, I think that anything that leads to confusion for
newcomers (thereby
discouraging community growth) had better have some very strong benefits.
That being said, I don't personally see a lot of benefit in this environment,
so I would
be a +1 to remove the distinction between the two branches.
----------------------------------------
Date: Thu, 13 Aug 2015 15:45:00 -0400
Subject: Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction
From: a...@adamtaft.com
To: dev@nifi.apache.org
The difficulties of using the gitflow workflow and the release process can
be significantly reduced with good tooling. I'm currently using the
jgit-flow [1][2] maven plugin with very good success. It handles and
manages feature, release, and hotfix branches seemlessly. And it avoids
common problems with the normal maven release plugin for gitflow.
Before abandoning gitflow, the community should seriously consider tooling
that makes it more usable. I'm not going to argue the merits of gitlab
flow or any other workflows. But clearly, abandoning gitflow because it's
"hard" is likely the wrong driver, if tooling exists to make it better.
[1]
http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/
[2] https://bitbucket.org/atlassian/jgit-flow/wiki/Home
On Thu, Aug 13, 2015 at 2:58 PM, Bryan Bende <bbe...@gmail.com> wrote:
If we worked on master and had a prod branch that was the last release,
then we have the same thing we do now, just with different names. This
would be GitLab Flow as Brandon pointed out.
That being said, I don't have experience with the release process, and
maybe the prod branch does not provide any value for us. The prod branch
would normally be used to create quick fix branches based off production,
or when doing automated/continuous deployments to a production system, but
if we aren't doing either of those things then maybe it is not worth it.
-Bryan
On Thu, Aug 13, 2015 at 2:23 PM, Brandon DeVries <b...@jhu.edu> wrote:
Personally, I still think GitLab Flow[1] is all we need for us to be
Really
Useful Engines.
[1] https://about.gitlab.com/2014/09/29/gitlab-flow/
Brandon
On Thu, Aug 13, 2015 at 2:15 PM Joe Witt <joew...@apache.org> wrote:
Resending
On Aug 13, 2015 12:22 PM, "Joe Witt" <joe.w...@gmail.com> wrote:
Team,
It was proposed by Ryan Blue on another thread that we consider
dropping the master vs develop distinction. In the interest of his,
in my view, very good point I didn't want it to get buried in that
thread.
[1] is the thread when we last discussed gitflow/develop/master on
entry to the incubator.
And from that thread here is the part I wish I had better understood
when the wise Mr Benson said it:
"Another issue with gitflow is the master branch. The master branch
is
supposed to get merged to for releases. The maven-release-plugin
won't
do that, and the jgitflow plugin is unsafe. So one option is to 'use
gitflow' but not bother with the master versus develop distinction,
the other is to do manual merges to master at release points."
I think we should follow this guidance: "'use gitflow' but not bother
with the master versus develop distinction". I say this from having
done the release management job now a couple of times including
having
done a 'hotfix'.
My comments here are not a rejection of that master/develop concept
in
general. It is simply pointing out that for the Apache NiFi
community
it is not adding value but is creating confusion and delay [2].
Thanks
Joe
[1] http://s.apache.org/GIW
[2] Sir Topham Hatt - Thomas and Friends (tm)
--
Ryan Blue
Software Engineer
Cloudera, Inc.
