+0. Our default branch is set to 'develop', so when you clone apache-nifi from git, you are automatically looking at the 'develop' branch, right? To me, this is a straight forward indicator of where I should be working.
I thought we set this up a little while ago to avoid the confusion? Dan Bress Software Engineer ONYX Consulting Services ________________________________________ From: Ryan Blue <b...@cloudera.com> Sent: Thursday, August 13, 2015 4:04 PM To: dev@nifi.apache.org Subject: Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction +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.
