nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction
Date Thu, 13 Aug 2015 20:22:14 GMT
Nope.  That is just what is shown in github as the default.
On Aug 13, 2015 4:15 PM, "Dan Bress" <dbress@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 <blue@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 <bbende@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 <brd@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 <joewitt@apache.org>
wrote:
> >>>>
> >>>>> Resending
> >>>>> On Aug 13, 2015 12:22 PM, "Joe Witt" <joe.witt@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message