[DISCUSS] Removal of the 'master' vs 'develop' distinction

[Joe Witt <jo...@gmail.com>]

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)

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Joe Witt <jo...@gmail.com>]

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 <jo...@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 <bu...@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 <ad...@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 <jo...@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 <ad...@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 <db...@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=86Neew@mail.gmail.com%3E
>>> > >>
>>> > >> Dan Bress
>>> > >> Software Engineer
>>> > >> ONYX Consulting Services
>>> > >>
>>> > >> ________________________________________
>>> > >> From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
>>> > >> wrote:
>>> > >> > >>>>
>>> > >> > >>>>> Resending
>>> > >> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Joe Witt <jo...@gmail.com>]

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 <bu...@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 <ad...@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 <jo...@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 <ad...@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 <db...@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=86Neew@mail.gmail.com%3E
>> > >>
>> > >> Dan Bress
>> > >> Software Engineer
>> > >> ONYX Consulting Services
>> > >>
>> > >> ________________________________________
>> > >> From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
>> > >> wrote:
>> > >> > >>>>
>> > >> > >>>>> Resending
>> > >> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Sean Busbey <bu...@cloudera.com>]

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 <ad...@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 <jo...@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 <ad...@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 <db...@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=86Neew@mail.gmail.com%3E
> > >>
> > >> Dan Bress
> > >> Software Engineer
> > >> ONYX Consulting Services
> > >>
> > >> ________________________________________
> > >> From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
> > >> wrote:
> > >> > >>>>
> > >> > >>>>> Resending
> > >> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Adam Taft <ad...@adamtaft.com>]

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 <jo...@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 <ad...@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 <db...@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=86Neew@mail.gmail.com%3E
> >>
> >> Dan Bress
> >> Software Engineer
> >> ONYX Consulting Services
> >>
> >> ________________________________________
> >> From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
> >> wrote:
> >> > >>>>
> >> > >>>>> Resending
> >> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.
> >> >
> >>
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Joe Witt <jo...@gmail.com>]

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 <ad...@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 <db...@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=86Neew@mail.gmail.com%3E
>>
>> Dan Bress
>> Software Engineer
>> ONYX Consulting Services
>>
>> ________________________________________
>> From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
>> wrote:
>> > >>>>
>> > >>>>> Resending
>> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.
>> >
>>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Adam Taft <ad...@adamtaft.com>]

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 <db...@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=86Neew@mail.gmail.com%3E
>
> Dan Bress
> Software Engineer
> ONYX Consulting Services
>
> ________________________________________
> From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
> wrote:
> > >>>>
> > >>>>> Resending
> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.
> >
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Dan Bress <db...@onyxconsults.com>]

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=86Neew@mail.gmail.com%3E

Dan Bress
Software Engineer
ONYX Consulting Services

________________________________________
From: Joe Witt <jo...@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" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org> wrote:
> >>>>
> >>>>> Resending
> >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Mike Drob <ma...@cloudera.com>]

I think you can change what branch is checked out by default by updating
remote/HEAD?

On Thu, Aug 13, 2015 at 3:22 PM, Joe Witt <jo...@gmail.com> wrote:

> Nope.  That is just what is shown in github as the default.
> On Aug 13, 2015 4:15 PM, "Dan Bress" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org>
> wrote:
> > >>>>
> > >>>>> Resending
> > >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.
> >
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Joe Witt <jo...@gmail.com>]

Nope.  That is just what is shown in github as the default.
On Aug 13, 2015 4:15 PM, "Dan Bress" <db...@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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org> wrote:
> >>>>
> >>>>> Resending
> >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Dan Bress <db...@onyxconsults.com>]

+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 <bl...@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: adam@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 <bb...@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 <br...@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 <jo...@apache.org> wrote:
>>>>
>>>>> Resending
>>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Ryan Blue <bl...@cloudera.com>]

+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: adam@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 <bb...@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 <br...@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 <jo...@apache.org> wrote:
>>>>
>>>>> Resending
>>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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.

RE: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Mark Payne <ma...@hotmail.com>]

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: adam@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 <bb...@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 <br...@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 <jo...@apache.org> wrote:
>>>
>>>> Resending
>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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)
>>>>>
>>>>
>>>
>>
 		 	   		  

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Adam Taft <ad...@adamtaft.com>]

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 <bb...@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 <br...@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 <jo...@apache.org> wrote:
> >
> > > Resending
> > > On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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)
> > > >
> > >
> >
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Bryan Bende <bb...@gmail.com>]

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 <br...@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 <jo...@apache.org> wrote:
>
> > Resending
> > On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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)
> > >
> >
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Brandon DeVries <br...@jhu.edu>]

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 <jo...@apache.org> wrote:

> Resending
> On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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)
> >
>

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

[Joe Witt <jo...@apache.org>]

Resending
On Aug 13, 2015 12:22 PM, "Joe Witt" <jo...@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)
>