So sounds like we can set the default to develop whenever it is cloned. That is a good start. We still have to articulate that we have 'master' and 'develop' and help folks understand why.
So on that second part, let's help ourselves understand 'why' for our own community. For me that is what I'm pushing back on. Why is that helpful for *this* apache nifi community? Having done the release management gig a couple times now I am not seeing the value add for *this* project. There too we must be clear about how these models can be applied to generating value apache releases. I am open minded to this having value. That is why i was supportive of the idea back in Nov/Dec. But over the past 8 months or so I've only seen it as an 'extra step' for an already difficult RM task and as something that creates confusion. So for me, this is an easy discussion if we can clearly articulate value of the master/develop distinction. Thanks Joe On Thu, Aug 13, 2015 at 4:44 PM, Adam Taft <a...@adamtaft.com> wrote: > The default branch is not a feature of GitHub, GitLab, etc. It's a feature > of git itself. On the 'bare' repository, issue this command: > > git symbolic-ref HEAD refs/heads/*mybranch* > > Effectively, this is what GitHub is doing. It should be possible to do > with the Apache git host as well. > > > > On Thu, Aug 13, 2015 at 4:28 PM, Dan Bress <dbr...@onyxconsults.com> wrote: > >> Ah, I didn't realize that was a github only thing [1], I take-back my >> early comment and can now see how this is confusing. >> >> [1] >> http://mail-archives.apache.org/mod_mbox/nifi-dev/201501.mbox/%3CCALhtWke141nTsCdA4tHnZXOJ1UGhtZurLwvDsjBxH_G=86n...@mail.gmail.com%3E >> >> Dan Bress >> Software Engineer >> ONYX Consulting Services >> >> ________________________________________ >> From: Joe Witt <joe.w...@gmail.com> >> Sent: Thursday, August 13, 2015 4:22 PM >> To: dev@nifi.apache.org >> Subject: Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction >> >> Nope. That is just what is shown in github as the default. >> On Aug 13, 2015 4:15 PM, "Dan Bress" <dbr...@onyxconsults.com> 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 <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. >> > >>
