Nope. That is just what is shown in github as the default. On Aug 13, 2015 4:15 PM, "Dan Bress" <[email protected]> wrote:
> +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 <[email protected]> > Sent: Thursday, August 13, 2015 4:04 PM > To: [email protected] > 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: [email protected] > >> To: [email protected] > >> > >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > >>>> > >>>>> Resending > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <[email protected]> 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. >
