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 Sun, 16 Aug 2015 19:19:34 GMT
Ok - I've submitted an INFRA ticket to move the default branch back to
'master'.  [1].

Now working the actual merge of develop to master.  Once that is done
and the INFRA ticket is done will remove the remote/origin develop
branch. [2]

[1] https://issues.apache.org/jira/browse/INFRA-10130
[2] https://issues.apache.org/jira/browse/NIFI-857

Thanks
Joe

On Sat, Aug 15, 2015 at 10:09 AM, Joe Witt <joe.witt@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 <busbey@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 <adam@adamtaft.com> wrote:
>>
>>> It's really a principle and style preference.  Each of the git workflows
>>> have pros/cons, but they are each viable.  There's nothing that says that
>>> gitflow is superior to other workflows.
>>>
>>> Gitflow has the unique advantage that, by default, master only has exactly
>>> the finished product tags on it, and the latest release is always at the
>>> master's head.  If you clone and checkout master, you can safely assume
>>> you're getting the most stable release, which is what most non-contributors
>>> want when they download source code.
>>>
>>> If the community doesn't value this principle and master can just be a
>>> free-for-all, that's OK too.  It's going to be tougher to apply hotfixes to
>>> existing stable releases, in my opinion, which might create more cries for
>>> help when a bug is introduced during a release.  There is a bit more "wild
>>> west" and "forward only" approach when removing the gitflow methodology.
>>>
>>> Using good tooling, again like my reference to jgitflow, would make the RM
>>> process much easier.  If proper tooling exists, the RM process shouldn't be
>>> an obstacle.  If the right tooling does not exist, that's a different
>>> story, of course.
>>>
>>> It might be good to have a survey of other Apache and open source project
>>> development workflows.  I was under the assumption that the "forking
>>> workflow" is becoming the most common for open source contributions (with
>>> Github's rise to dominance), and gitflow being a close second, but that's
>>> just my guess, not research oriented.
>>>
>>> I personally have no vote or stake on this issue.  I'm just chiming in some
>>> thoughts.
>>>
>>>
>>>
>>> On Thu, Aug 13, 2015 at 4:55 PM, Joe Witt <joe.witt@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 <adam@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 <dbress@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 <joe.witt@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" <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.
>>> > >> >
>>> > >>
>>> >
>>>
>>
>>
>>
>> --
>> Sean

Mime
View raw message