My understanding is - we should always merge the fixes to both *develop
and *master branches. Merging to develop branch should be mandatory as
that’s the place where automatic nightly builds + the regression tests are
run against. That’s what the article from Daan’s email says:
Master branch: "We consider origin/master to be the main branch where the
source code of HEAD always reflects aproduction-ready state.”
Develop branch: "We consider origin/develop to be the main branch where
the source code of HEAD always reflects a state with the latest delivered
development changes for the next release. Some would call this the
“integration branch”. This is where any automatic nightly builds are built
from. When the source code in the develop branch reaches a stable point
and is ready to be released, all of the changes should be merged back into
master"
Only if the tests pass on *develop branch, the changes get merged to
master branch.
Daan, please confirm if that’s how we are planning to operate. This thread
also brings another question: are we going to run automation/CI against
both *develop/*master branches? On *develop to ensure that the branch is
ready to be merged to master. And on *master to ensure that the code is
production ready. And if we are planning to run it on both branches, how
often should we do it on one vs another?
-Alena.
On 7/29/14, 1:06 PM, "sowmya samala" <skarna...@gmail.com> wrote:
>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
>>
