Ok - I've submitted an INFRA ticket to move the default branch back to 'master'. [1].
Now working the actual merge of develop to master. Once that is done and the INFRA ticket is done will remove the remote/origin develop branch. [2] [1] https://issues.apache.org/jira/browse/INFRA-10130 [2] https://issues.apache.org/jira/browse/NIFI-857 Thanks Joe On Sat, Aug 15, 2015 at 10:09 AM, Joe Witt <joe.w...@gmail.com> wrote: > Hello > > Wanted to summarize as the thread appears to have died down. There > appears to be consensus about the cost/benefit of our current process > being out of alignment. The current model is creating confusion for > newcomers and veterans alike and creating more work for an already > highly detailed release management process as needed within Apache. > > The plan is to then to retain all of our current processes except that > we will remove the 'develop' branch and simply have all work done on > the 'master' branch. Our release process already takes care of > generating tags of releases which we can (and have) used for hotfix > release if needed. > > There have been a couple of other workflows/approaches identified > which warrant further analysis and distillation to apply against the > act of building valid apache releases [1][2]. > > I am frankly very happy that this discussion combined with the > addition of independent git repositories for nifi-site and nifi-maven > means that our project will be much more in alignment with what folks > expect in apache. > > Thanks all for participating in the discussion. > > Joe > > [1] https://about.gitlab.com/2014/09/29/gitlab-flow/ > [2] > http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/ > > On Thu, Aug 13, 2015 at 11:02 PM, Sean Busbey <bus...@cloudera.com> wrote: >> For downstream users of an apache project, "downloading source code" should >> be downloading a PMC sanctioned release off of the mirrors. I suspect that >> this obviates most of the value from making master something other than >> "where development lands." >> >> What's harder about creating hotfix releases by branching off of the >> previous release tag? That's what we do over in HBase, and I've never seen >> it add meaningful overhead. >> >> On Thu, Aug 13, 2015 at 4:23 PM, Adam Taft <a...@adamtaft.com> wrote: >> >>> It's really a principle and style preference. Each of the git workflows >>> have pros/cons, but they are each viable. There's nothing that says that >>> gitflow is superior to other workflows. >>> >>> Gitflow has the unique advantage that, by default, master only has exactly >>> the finished product tags on it, and the latest release is always at the >>> master's head. If you clone and checkout master, you can safely assume >>> you're getting the most stable release, which is what most non-contributors >>> want when they download source code. >>> >>> If the community doesn't value this principle and master can just be a >>> free-for-all, that's OK too. It's going to be tougher to apply hotfixes to >>> existing stable releases, in my opinion, which might create more cries for >>> help when a bug is introduced during a release. There is a bit more "wild >>> west" and "forward only" approach when removing the gitflow methodology. >>> >>> Using good tooling, again like my reference to jgitflow, would make the RM >>> process much easier. If proper tooling exists, the RM process shouldn't be >>> an obstacle. If the right tooling does not exist, that's a different >>> story, of course. >>> >>> It might be good to have a survey of other Apache and open source project >>> development workflows. I was under the assumption that the "forking >>> workflow" is becoming the most common for open source contributions (with >>> Github's rise to dominance), and gitflow being a close second, but that's >>> just my guess, not research oriented. >>> >>> I personally have no vote or stake on this issue. I'm just chiming in some >>> thoughts. >>> >>> >>> >>> On Thu, Aug 13, 2015 at 4:55 PM, Joe Witt <joe.w...@gmail.com> wrote: >>> >>> > 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. >>> > >> > >>> > >> >>> > >>> >> >> >> >> -- >> Sean
