If a bug fix branch is cut off from Develop branch then all the current
changes like new feature merges, new enhancement/development of a future
release will also get merged to Master branch instead of a Release branch
once the bug fix branch is merged. Our motto about keeping Master is to
maintain a stable branch right and to my knowledge Develop branch is used
for parallel development.
And for any production fixes, a hot fix branch should be created from a
stable branch like Master only. If it is a Release bug fix then the branch
should be created from Release branch and then merged{if we plan to commit
release bug fixes in a separate branch instead of a Release branch}.
Please correct me if I am wrong in understanding.
On Tue, Jul 29, 2014 at 3:04 PM, Tanner Danzey <arkan...@gmail.com> wrote:
> Ah. I simply misunderstood. That sounds very reasonable to me.
>
>
> On Tue, Jul 29, 2014 at 1:59 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
> > Tanner,
> >
> > My question was about bugs happening not in production (the branch that
> is
> > already released). For those hot fix branches are needed - and that
> > described in the article. My question was about new bugs happening either
> > in the *developer branch or *release branch that hasn’t been released
> yet.
> > In CS “git commit” document we should clearly define the criteria for the
> > bugs requiring separate branch vs bugs that can be committed to the
> > *developer/*release branch directly.
> >
> > Thanks,
> > Alena.
> >
> > On 7/29/14, 11:53 AM, "Tanner Danzey" <arkan...@gmail.com> wrote:
> >
> > >This seems like a reasonable use scenario, but is it not what the
> article
> > >located at @ http://nvie.com/posts/a-successful-git-branching-model/
> > >already describes?
> > >
> > >
> > >On Tue, Jul 29, 2014 at 1:45 PM, Alena Prokharchyk <
> > >alena.prokharc...@citrix.com> wrote:
> > >
> > >> I would rather say that the bug fix branch should be cut from
> *developer
> > >> branch, not master, then merged to *developer upon fixing so all the
> > >>tests
> > >> are run for the fix. Only after tests pass, the merge to master from
> > >> developer should be done. If the bug doesn’t require branching out
> (see
> > >> the proposed criteria in my other email), it should be fixed directly
> in
> > >> *developer branch. Nothing should go to the master branch directly
> > >> bypassing the developer branch.
> > >>
> > >> -Alena.
> > >>
> > >> On 7/29/14, 11:37 AM, "sowmya samala" <skarna...@gmail.com> wrote:
> > >>
> > >> >I think it would be good if the bug fixes are delivered to the
> Release
> > >> >branch only if they are found in that particular Release. But if
> there
> > >>are
> > >> >any productions fixes then a new hot fix branch should be cut out of
> > >> >Master
> > >> >and once the changes are made and released, the branch should be
> merged
> > >> >back to Master. All the child branches should get these latest
> changes
> > >> >from
> > >> >Master.
> > >> >
> > >> >Please share your thoughts on this ?
> > >> >
> > >> >
> > >> >On Tue, Jul 29, 2014 at 2:32 PM, Tanner Danzey <arkan...@gmail.com>
> > >> wrote:
> > >> >
> > >> >> For what it's worth, I support the move to a git-flow project
> > >>layout. It
> > >> >> seems to have a more sensible structure than what ACS currently
> has,
> > >> >> although I'm not going to say that ACS's current structure has not
> > >>been
> > >> >> sufficient, just that it simply seems to be the time for change.
> The
> > >> >> git-flow model seems to be a little easier to form a model of in
> > >>one's
> > >> >> head.
> > >> >>
> > >> >>
> > >> >> On Tue, Jul 29, 2014 at 1:20 PM, Alena Prokharchyk <
> > >> >> alena.prokharc...@citrix.com> wrote:
> > >> >>
> > >> >> >
> > >> >> >
> > >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <nate.gor...@appcore.com>
> > >>wrote:
> > >> >> >
> > >> >> > >This might be somewhere that we can extend the basic concept of
> > >> >>gitflow.
> > >> >> > >If
> > >> >> > >there are trivial fixes (I forgot an edge case in an if
> > >>statement),
> > >> >>it
> > >> >> > >probably isn't necessary to branch the release and merge back,
> > >>but if
> > >> >> you
> > >> >> > >need to do some significant work (I broke one of the other
> > >> >>hypervisors
> > >> >> and
> > >> >> > >need to refactor something), or want feedback/discussion it
> would
> > >> >> probably
> > >> >> > >be easier to branch from the release branch, push the branch to
> > >>the
> > >> >> > >central
> > >> >> > >repo to allow feedback/testing from others, and then merge back
> in
> > >> >>once
> > >> >> it
> > >> >> > >has been resolved.
> > >> >> > >
> > >> >> > >I think the general concept is to default to creating a branch
> any
> > >> >>time
> > >> >> > >you
> > >> >> > >are doing something (I'm sure there are exceptions, but this
> > >>would be
> > >> >> the
> > >> >> > >default mode of operation). That way whole
> > >> >> > >features/fixes/releases/testing/experimentation/magic can be
> > >>worked
> > >> >>on
> > >> >> in
> > >> >> > >parallel and merged/reverted as a unit. It also encourages
> > >> >>collaboration
> > >> >> > >because it is easy to identify a unit of work that needs to be
> > >> >> discussed.
> > >> >> > >
> > >> >> > >But really, it would be easier to cut the release if there
> weren't
> > >> >>bugs
> > >> >> > >that we had to work through ;-)
> > >> >> >
> > >> >> > Agree:-) But the same can apply to *develop branch. So we should
> > >> >>decide
> > >> >> > for which bugs the hot fix branch should be cut, and which fixes
> > >>can
> > >> >>go
> > >> >> > directly to *develop/*release branches. This criteria has to be
> > >> >>defined
> > >> >> in
> > >> >> > the doc, and be based on the a) bug severity b) number of people
> > >>who
> > >> >>work
> > >> >> > on the bug - if more than one, then we cut the new branch c)
> > >> >> > feedback/review is needed for the bug d) anything else?
> > >> >> >
> > >> >> > -Alena
> > >> >> >
> > >> >> > >
> > >> >> > >Thanks,
> > >> >> > >
> > >> >> > >-Nate
> > >> >> > >
> > >> >> > >
> > >> >> > >On Tue, Jul 29, 2014 at 11:59 AM, Alena Prokharchyk <
> > >> >> > >alena.prokharc...@citrix.com> wrote:
> > >> >> > >
> > >> >> > >> I have one more question in addition to what Sheng asked.
> > >>Document
> > >> >> > >> http://nvie.com/posts/a-successful-git-branching-model/
> > mentions
> > >> >>that
> > >> >> > >>the
> > >> >> > >> *hotfix branch should be created for the blocker/critical bugs
> > >>in
> > >> >>the
> > >> >> > >> current production release. What about bugs happenning in the
> > >> >>*release
> > >> >> > >> branch (the one that hasn't been released yet)? Should we fix
> > >>them
> > >> >> > >> directly in the *release branch, or should we branch out off
> the
> > >> >> > >>*release
> > >> >> > >> branch, fix the problem, and merge the fix to *release? Would
> > >>the
> > >> >>rule
> > >> >> > >>be
> > >> >> > >> the same for Major bug as opposed to Critical one?
> > >> >> > >>
> > >> >> > >> Thank you,
> > >> >> > >> Alena.
> > >> >> > >>
> > >> >> > >>
> > >> >> > >>
> > >> >> > >> On 7/29/14, 12:52 AM, "Leo Simons" <
> lsim...@schubergphilis.com>
> > >> >> wrote:
> > >> >> > >>
> > >> >> > >> >On Jul 29, 2014, at 5:45 AM, Sheng Yang <sh...@yasker.org>
> > >>wrote:
> > >> >> > >> >> I am trying to catch up, by reading the thread and checking
> > >> >>what's
> > >> >> > >> >>gitflow
> > >> >> > >> >> etc, but could someone already familiar with the topic give
> > >>an
> > >> >> > >>overview
> > >> >> > >> >>of
> > >> >> > >> >> the issue?
> > >> >> > >> >>
> > >> >> > >> >> For example, we can start by asking these questions:
> > >> >> > >> >> 1. What's the issue with current development process?
> > >> >> > >> >
> > >> >> > >> >Right now it is quite hard to get to a stable release, or to
> > >> >>produce
> > >> >> > >>high
> > >> >> > >> >quality contributions, and this happens in part because of
> the
> > >>git
> > >> >> > >> >workflow in use.
> > >> >> > >> >
> > >> >> > >> >Cherry-picking is an approach where git can provide 0
> > >>assistance
> > >> >>with
> > >> >> > >> >branch and merge management. Read
> > >> >> > >> >
> > >> >>http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> > >> >> > >> >for an introduction to that subject, for example.
> > >> >> > >> >
> > >> >> > >> >> 2. What's the purposed new approach to the process?
> > >> >> > >> >
> > >> >> > >> >To use a branch/merge workflow rather than a cherry-pick
> > >>workflow,
> > >> >> > >> >preserving commit ids across branches.
> > >> >> > >> >
> > >> >> > >> >To adopt a specific well-documented workflow called git-flow
> > >>that
> > >> >>has
> > >> >> > >> >tool support. Read
> > >> >> > >> > http://nvie.com/posts/a-successful-git-branching-model/
> > >> >> > >> >for an introduction to git-flow.
> > >> >> > >> >
> > >> >> > >> >To then tune this workflow to cloudstack. In particular, so
> > >>far,
> > >> >>I¹ve
> > >> >> > >> >noted
> > >> >> > >> >* not deleting release branches once releases are finished
> > >> >> > >> >* consider using support/ branches for point releases rather
> > >>than
> > >> >> > >>hotfix/
> > >> >> > >> >branches
> > >> >> > >> >
> > >> >> > >> >Note that this new workflow implies a variety of things,
> > >> >>including:
> > >> >> > >> >* sharing responsibility for merges among many committers (as
> > >> >>opposed
> > >> >> > >>to
> > >> >> > >> >a release manager responsible for cherry picking)
> > >> >> > >> >* distributing the Œmerge pain¹ throughout the development
> > >> >>process as
> > >> >> > >> >features finish up (rather than Œbig bang¹ during release
> time)
> > >> >> > >> >
> > >> >> > >> >> 3. What's the pro/con of the new process? And what's the
> > >> >>pro/con of
> > >> >> > >>the
> > >> >> > >> >>old
> > >> >> > >> >> one?
> > >> >> > >> >
> > >> >> > >> >This is very difficult to summarize fairly.
> > >> >> > >> >
> > >> >> > >> >IMHO the only advantage of the old process is that it is what
> > >> >> everyone
> > >> >> > >> >knows already. It¹s main downsides are that it is not using
> > >>git¹s
> > >> >> > >> >excellent branch management features, does not allow
> comparing
> > >>or
> > >> >> > >>merging
> > >> >> > >> >between branches, requires contributions to be re-written for
> > >> >> multiple
> > >> >> > >> >branches, and encourages developers to ignore merge conflicts
> > >> >>until
> > >> >> > >> >release time.
> > >> >> > >> >
> > >> >> > >> >IMHO any workflow that does not rely on cherry-picking has
> only
> > >> >> > >> >advantages compared to the current process.
> > >> >> > >> >
> > >> >> > >> >Git-flow has many people that like it and many people that
> > >>don¹t.
> > >> >> But,
> > >> >> > >> >the people that don¹t like it usually use another
> branch/merge
> > >> >>model,
> > >> >> > >>not
> > >> >> > >> >cherry-picking. It¹s main advantages among available
> > >>branch/merge
> > >> >> > >> >workflwos are being well-defined, oft-used and
> tool-supported.
> > >> >> > >> >
> > >> >> > >> >> That would make the question much more clear.
> > >> >> > >> >
> > >> >> > >> >Hope this helps,
> > >> >> > >> >
> > >> >> > >> >
> > >> >> > >> >cheers,
> > >> >> > >> >
> > >> >> > >> >
> > >> >> > >> >Leo
> > >> >> > >> >
> > >> >> > >>
> > >> >> > >>
> > >> >> > >
> > >> >> > >
> > >> >> > >--
> > >> >> > >
> > >> >> > >
> > >> >> > >*Nate Gordon*Director of Technology | Appcore - the business of
> > >>cloud
> > >> >> > >computing®
> > >> >> > >
> > >> >> > >Office +1.800.735.7104 | Direct +1.515.612.7787
> > >> >> > >nate.gor...@appcore.com | www.appcore.com
> > >> >> > >
> > >> >> >
> > >>
> >
> >>>>>----------------------------------------------------------------------
> > >> >> > >
> > >> >> > >The information in this message is intended for the named
> > >>recipients
> > >> >> only.
> > >> >> > >It may contain information that is privileged, confidential or
> > >> >>otherwise
> > >> >> > >protected from disclosure. If you are not the intended
> recipient,
> > >>you
> > >> >> are
> > >> >> > >hereby notified that any disclosure, copying, distribution, or
> the
> > >> >> taking
> > >> >> > >of any action in reliance on the contents of this message is
> > >>strictly
> > >> >> > >prohibited. If you have received this e-mail in error, do not
> > >>print
> > >> >>it
> > >> >> or
> > >> >> > >disseminate it or its contents. In such event, please notify the
> > >> >>sender
> > >> >> by
> > >> >> > >return e-mail and delete the e-mail file immediately thereafter.
> > >> >>Thank
> > >> >> > >you.
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >> --
> > >> >> *Tanner Danzey*
> > >> >> Systems Engineer
> > >> >> Northstar Technology Group
> > >> >> arkan...@gmail.com / tanner.dan...@northstar-tg.com
> > >> >> (701) 237-9096 x7122
> > >> >>
> > >>
> > >>
> > >
> > >
> > >--
> > >*Tanner Danzey*
> > >Systems Engineer
> > >Northstar Technology Group
> > >arkan...@gmail.com / tanner.dan...@northstar-tg.com
> > >(701) 237-9096 x7122
> >
> >
>
>
> --
> *Tanner Danzey*
> Systems Engineer
> Northstar Technology Group
> arkan...@gmail.com / tanner.dan...@northstar-tg.com
> (701) 237-9096 x7122
>
