[DISCUSS] git commit proces

[Daan Hoogland <da...@gmail.com>]

H,

I see a lot of commits happening directly on the master branch. Yet
there were no counter arguments against the proposed gitflow and the
discussion around it. This leaves me with the idea that the thread is
largely ignored by the community. It is my understanding that we
agreed never to commit anything to master anymore that hasn't been
first committed to a branch and is merged back to master (instead of
cherry-picked). What mistake in thinking am I making here?

thanks,
-- 
Daan

Re: [DISCUSS] git commit proces

[Rohit Yadav <ro...@shapeblue.com>]

Hi Daan,

We've a page on Git [1] and recommended workflow for committers and
non-committers, should we update the workflow we want for committers
there and start a separate vote thread?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git

Regards.

Daan Hoogland wrote:
> Let me explain a little more about this lat mail of mine.
> I was assuming a lot of context that most people may not have.
> We want to start working differently with respect to our release
> procedure and branching habits. The proposals that are out there and
> about to be voted for are going to require a lot of work of a few
> people and a lot of discipline from all of us.
>
> My idea was to first vote for some of the habits that are part of the
> gitflow discipline, but I am not strong opinionated about that.
>
> I do want to prevent that we go for a grand proposal to completely
> change our way of moving forward (not just the way we move forward)
> while there are potentially people opposing to this way of working.
>
> So please give a +1/0/-1 to the general idea now, so we fell
> comfortable spending the time in devising a new release
> schedule/mechanism.
>
> some of the highlights are:
>
> it will start with 4.5 (4.4.x will be done with the old manual
> cherry-pick process)
> it will require everybody to create a branch for every fix or feature
> they will contribute.
> it will require devs to work mainly on a new branch call 'develop'
> it will be every bodies responsibility to ensure that 'master' is at
> all times releasable
>
> thanks,
> Daan
>
> On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland<da...@gmail.com>  wrote:
>> I am not for a grand proposal but ok, I can live with it.
>>
>> It would be easiest to just vote for using the gitflow model.
>> Leo is preparing a page on how to do it. I don't know what the status
>> is on it. The vote for my part would be on the contents of that page.
>>
>> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
>> <mi...@solidfire.com>  wrote:
>>> Yeah, I was under the impression this decision would require a vote and
>>> formal announcement, if it passes.
>>>
>>> On Monday, July 28, 2014, Hugo Trippaers<hu...@trippaers.nl>  wrote:
>>>
>>>> Agreed,  this kind of important decisions should be made by a vote.
>>>>
>>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
>>>> condensed summary of the thread?
>>>>
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>>
>>>> On 28 jul. 2014, at 14:07, Ian Duffy<ian@ianduffy.ie<javascript:;>>
>>>> wrote:
>>>>
>>>>> +1 to what Erik said.
>>>>>
>>>>>
>>>>> On 28 July 2014 13:04, Erik Weber<terbolous@gmail.com<javascript:;>>
>>>> wrote:
>>>>>> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland<daan.hoogland@gmail.com
>>>> <javascript:;>>
>>>>>> wrote:
>>>>>>
>>>>>>> H,
>>>>>>>
>>>>>>> I see a lot of commits happening directly on the master branch. Yet
>>>>>>> there were no counter arguments against the proposed gitflow and the
>>>>>>> discussion around it. This leaves me with the idea that the thread is
>>>>>>> largely ignored by the community. It is my understanding that we
>>>>>>> agreed never to commit anything to master anymore that hasn't been
>>>>>>> first committed to a branch and is merged back to master (instead of
>>>>>>> cherry-picked). What mistake in thinking am I making here?
>>>>>>>
>>>>>>>
>>>>>> Not familiar with bylaws and the such, but wouldn't a change like this
>>>>>> require some sort of voting and potentially a more formal information?
>>>>>>
>>>>>> Requiring everyone to read through a 50+ replies mail thread and
>>>> comprehend
>>>>>> it could be a bit much.
>>>>>>
>>>>>> I would suggest an updated document that explain the expected workflow.
>>>>>>
>>>>>> --
>>>>>> Erik
>>>>>>
>>>>
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>>
>> --
>> Daan
>
>
>

--
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab


Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] git commit proces

[Nate Gordon <na...@appcore.com>]

I think the general rule for fixes is to branch from where the bug is. If
the bug is in prod, branch from master. If the bug is in the release
process, branch from the release branch. If the bug is in development,
branch from development. The previous comment about pulling dev code into
master via a bugfix on development is a very relevant problem. In theory,
all bugfixes can and should be merged multiple places. Master hotfixes
should go to develop/support/hotfix branches if they are affected by the
same bug, release bugfixes will get merged back into development once the
release branch is done. Dev bugfixes obviously end up in the development
branch since they started there.

I realize that testing is commonly done on the dev branch, but we should
probably do full CI/testing process on the release, hotfix, and master
branches as well to ensure quality. Heck, I would vote for a lighter scale
build for all branches on every commit, but we will need more
infrastructure and automation to support that.

As for when to create a branch, I would personally lean towards only
allowing direct commits on the release branch and only if they are trivial
single file and commit fixes. If it is more than one commit, or more than
one file, I would vote for it being a branch, but I might be a bit extreme.
Especially if the RM wants to manage what goes into the release/hotfix
branch to help control stability/quality. Branches are so trivial in git,
there is very little motivation not to use them wherever possible.

Thanks,

-Nate


On Tue, Jul 29, 2014 at 3:06 PM, sowmya samala <sk...@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 <ar...@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.Prokharchyk@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" <ar...@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.Prokharchyk@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" <sk...@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 <arkaniad@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.Prokharchyk@citrix.com> wrote:
> > > >> >>
> > > >> >> >
> > > >> >> >
> > > >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <
> > LSimons@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.gordon@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
> > > >> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> > > >> >> (701) 237-9096 x7122
> > > >> >>
> > > >>
> > > >>
> > > >
> > > >
> > > >--
> > > >*Tanner Danzey*
> > > >Systems Engineer
> > > >Northstar Technology Group
> > > >arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> > > >(701) 237-9096 x7122
> > >
> > >
> >
> >
> > --
> > *Tanner Danzey*
> > Systems Engineer
> > Northstar Technology Group
> > arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> > (701) 237-9096 x7122
> >
>



-- 


*Nate Gordon*Director of Technology | Appcore - the business of cloud
computing®

Office +1.800.735.7104  |  Direct +1.515.612.7787
nate.gordon@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.

Re: [DISCUSS] git commit proces

[Erik Weber <te...@gmail.com>]

I'm not sure this applies to hotfixes to previous versions, ie. not the
current master release.

The hotfix might not code wise apply to the current develop/master at all.

Assume that we one year from now, after releasing 4.5 and 4.6 using
gitflow, and are working towards a 4.7 in develop, we need to issue a
hotfix to 4.5 due to a security breach or similar. The issue could be gone
from develop because of refactoring or something else, but would still need
to be fixed for 4.5 (and 4.6 if the problem exists there) if that's still
supported.

which leads to my question; what's the support status for releases? how
long do we support them?

someone (can't remember the name), mentioned it could be used as a support
release/branch in gitflow terms.


Erik


On Tue, Jul 29, 2014 at 10:23 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> 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" <sk...@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 <ar...@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.Prokharchyk@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" <ar...@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.Prokharchyk@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" <sk...@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
> >><ar...@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.Prokharchyk@citrix.com> wrote:
> >> > >> >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <
> >> LSimons@schubergphilis.com>
> >> > >> >> wrote:
> >> > >> >> > >>
> >> > >> >> > >> >On Jul 29, 2014, at 5:45 AM, Sheng Yang <sheng@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.gordon@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
> >> > >> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> >> > >> >> (701) 237-9096 x7122
> >> > >> >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> > >--
> >> > >*Tanner Danzey*
> >> > >Systems Engineer
> >> > >Northstar Technology Group
> >> > >arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> >> > >(701) 237-9096 x7122
> >> >
> >> >
> >>
> >>
> >> --
> >> *Tanner Danzey*
> >> Systems Engineer
> >> Northstar Technology Group
> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> >> (701) 237-9096 x7122
> >>
>
>

Re: [DISCUSS] git commit proces

[Alena Prokharchyk <Al...@citrix.com>]

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" <sk...@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 <ar...@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.Prokharchyk@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" <ar...@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.Prokharchyk@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" <sk...@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
>><ar...@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.Prokharchyk@citrix.com> wrote:
>> > >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <
>> LSimons@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.gordon@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
>> > >> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>> > >> >> (701) 237-9096 x7122
>> > >> >>
>> > >>
>> > >>
>> > >
>> > >
>> > >--
>> > >*Tanner Danzey*
>> > >Systems Engineer
>> > >Northstar Technology Group
>> > >arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>> > >(701) 237-9096 x7122
>> >
>> >
>>
>>
>> --
>> *Tanner Danzey*
>> Systems Engineer
>> Northstar Technology Group
>> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>> (701) 237-9096 x7122
>>

Re: [DISCUSS] git commit proces

[sowmya samala <sk...@gmail.com>]

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 <ar...@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.Prokharchyk@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" <ar...@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.Prokharchyk@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" <sk...@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 <ar...@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.Prokharchyk@citrix.com> wrote:
> > >> >>
> > >> >> >
> > >> >> >
> > >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <
> LSimons@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.gordon@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
> > >> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> > >> >> (701) 237-9096 x7122
> > >> >>
> > >>
> > >>
> > >
> > >
> > >--
> > >*Tanner Danzey*
> > >Systems Engineer
> > >Northstar Technology Group
> > >arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> > >(701) 237-9096 x7122
> >
> >
>
>
> --
> *Tanner Danzey*
> Systems Engineer
> Northstar Technology Group
> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> (701) 237-9096 x7122
>

Re: [DISCUSS] git commit proces

[Tanner Danzey <ar...@gmail.com>]

Ah. I simply misunderstood. That sounds very reasonable to me.


On Tue, Jul 29, 2014 at 1:59 PM, Alena Prokharchyk <
Alena.Prokharchyk@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" <ar...@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.Prokharchyk@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" <sk...@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 <ar...@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.Prokharchyk@citrix.com> wrote:
> >> >>
> >> >> >
> >> >> >
> >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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
> >> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> >> >> (701) 237-9096 x7122
> >> >>
> >>
> >>
> >
> >
> >--
> >*Tanner Danzey*
> >Systems Engineer
> >Northstar Technology Group
> >arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> >(701) 237-9096 x7122
>
>


-- 
*Tanner Danzey*
Systems Engineer
Northstar Technology Group
arkaniad@gmail.com / tanner.danzey@northstar-tg.com
(701) 237-9096 x7122

Re: [DISCUSS] git commit proces

[Alena Prokharchyk <Al...@citrix.com>]

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" <ar...@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.Prokharchyk@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" <sk...@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 <ar...@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.Prokharchyk@citrix.com> wrote:
>> >>
>> >> >
>> >> >
>> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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
>> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>> >> (701) 237-9096 x7122
>> >>
>>
>>
>
>
>-- 
>*Tanner Danzey*
>Systems Engineer
>Northstar Technology Group
>arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>(701) 237-9096 x7122

Re: [DISCUSS] git commit proces

[Tanner Danzey <ar...@gmail.com>]

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.Prokharchyk@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" <sk...@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 <ar...@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.Prokharchyk@citrix.com> wrote:
> >>
> >> >
> >> >
> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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
> >> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> >> (701) 237-9096 x7122
> >>
>
>


-- 
*Tanner Danzey*
Systems Engineer
Northstar Technology Group
arkaniad@gmail.com / tanner.danzey@northstar-tg.com
(701) 237-9096 x7122

Re: [DISCUSS] git commit proces

[Alena Prokharchyk <Al...@citrix.com>]

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" <sk...@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 <ar...@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.Prokharchyk@citrix.com> wrote:
>>
>> >
>> >
>> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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
>> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>> (701) 237-9096 x7122
>>

Re: [DISCUSS] git commit proces

[sowmya samala <sk...@gmail.com>]

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 <ar...@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.Prokharchyk@citrix.com> wrote:
>
> >
> >
> > On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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
> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
> (701) 237-9096 x7122
>

Re: [DISCUSS] git commit proces

[Tanner Danzey <ar...@gmail.com>]

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.Prokharchyk@citrix.com> wrote:

>
>
> On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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
arkaniad@gmail.com / tanner.danzey@northstar-tg.com
(701) 237-9096 x7122

Re: [DISCUSS] git commit proces

[Alena Prokharchyk <Al...@citrix.com>]

On 7/29/14, 11:05 AM, "Nate Gordon" <na...@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.Prokharchyk@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" <LS...@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.gordon@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.

Re: [DISCUSS] git commit proces

[Nate Gordon <na...@appcore.com>]

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 ;-)

Thanks,

-Nate


On Tue, Jul 29, 2014 at 11:59 AM, Alena Prokharchyk <
Alena.Prokharchyk@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" <LS...@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.gordon@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.

Re: [DISCUSS] git commit proces

[Alena Prokharchyk <Al...@citrix.com>]

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" <LS...@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
>

Re: [DISCUSS] git commit proces

[Rajani Karuturi <Ra...@citrix.com>]

4. Then, conflict would happen when you merge release/4.4. branch to
release/4.5. Since the version number changed to 4.4.1. You need to deal
with version number conflict every time when merge to upper release.


one empty merge with git merge -s ours after the version change and git would not complain again. git would assume that conflicts are resolved and that particular commit need not be merged again.
git merges are relative it won’t merge the entire tree each and every time.

~ Rajani

Re: [DISCUSS] git commit proces

[Sheng Yang <sh...@yasker.org>]

On Thu, Jul 31, 2014 at 12:55 AM, Leo Simons <LS...@schubergphilis.com>
wrote:

> On Jul 31, 2014, at 12:55 AM, Sheng Yang <sh...@yasker.org> wrote:
> > I suppose it would work like this:
> > 1. In the original model, every release branch would be deleted after
> merge
> > into develop and master branch. There is no release/4.4.1 or release/4.5
> > branch.
> > 2. Say we don't follow original model, when one release is released, you
> > keep it. Say we have release/4.4 and release/4.5. And currently we're
> > working on 4.7 which is develop branch, MASTER is 4.6.
> > 3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1.
> > 4. Then, conflict would happen when you merge release/4.4. branch to
> > release/4.5. Since the version number changed to 4.4.1. You need to deal
> > with version number conflict every time when merge to upper release.
> > 5. Suppose you dealt with version number change. New release/4.5 would
> > merge release/4.4 which merged release/4.3. Then you want to merge to
> > master because there is a fix. Well, dealt with version number change
> > conflict again.
> > 6. Then, you would need to merge master to develop branch?
> >
> > I am little worry about the conflict every time when merge happened.
> Seems
> > version number conflict need to be dealt with everytime, and probably
> some
> > other conflict. The conflict need to be solved may result in more
> > error-prone situation.
>
> Well, yes, _that_ would be horrible! :-)
>
> Fortunately a merge only considers things that haven’t been merged before.
> If V means ‘bump version’, given
>
> master -----------------------------------------
>          \                 / \
> r/4.5     V1---y----------V2  \
>                 \              \
> r/4.6            \              V3--z-----------
>                   \                /
> fix                x---------------
>
> because V1 is an ancestor of V3, when you merge x into r/4.6, git knows
> not to consider V1 commit again. It knows it only has to consider x. There
> is no conflict due to V1 or V2 at z. If you would do this
>
> master ------------------------------------------
>          \      \   /
> r/4.5     V1-----\-V2----------------------------
>                   \    \         \
> r/4.6              V3---\-----z——-\----------z2--
>                          \   /     \        /
> fix                       x—-       \      /
>                                      \    /
> fix2                                  x2--
>
> you will have a merge conflict once, at spot z, where you will have to
> resolve the conflict created by having conflicting ancestors V2 and V3. But
> you won’t have to deal with it at spot z2, since git will remember you
> already resolved that conflict before.
>
> As long as you merge, instead of cherry-pick.
>

If no matter how many times you merged from old release, you would only
need to solve version conflict once, that would be quite nice! Hope this
can get things done well.

Still, in this approach, one error in the old release would affect all the
following releases. That's something we need to be more careful than before.


> >> For example, the linux kernel has at least two active minor releases at
> >> any given time, and many more minor releases and forks going on at that
> >> same time, with hundreds (thousands?) of active developers, and even
> _they_
> >> don’t need freezes. Instead the power is in their choices of what they
> do
> >> and do not
> >
> > I've worked on Linux kernel for years,
>
> If you have experience with linux’ approach, I’d suggest you just look at
> git-flow as a massively simplified version of roughly that, which is easier
> to get into, something to hold on to while you develop experience and then
> good judgement [1] of when/what/where to merge. A reasonable starting
> point. Also, now I _really_ don’t understand why we have to have this
> discussion :)
>

IMO, git-flow is really different from Linux's approach.

Linux kernel never merge between different maintenance versions, and the
maintenance of stable tree is mostly made up of individual patches rather
than merge, using cherry-pick. Only large amount of fixes would need merge
probably.

Linux mainstream utilized merge is for pull in a large set of commits for
either feature or fixes. Not for maintain workflow.

Relative stable code based is maintained by subsystem maintainer, which a
feature would start from. After testing and mature the code, subsystem
maintainer would ask Linus to pull(merge) a specific tree for next merge
window.

To my understand, Linux's approach is much simple and straightforward than
git-flow:
1. Linus give 2 week merge window, merge everything he thinks proper from
subsystem maintainer(thinking about feature branch merge), then cut RC1.
2. No feature would be in after RC1. Linus would only pull fixes from
subsystem maintainer. Then cut on one RC about every 2 weeks.
3. When community think the release is stable enough after a few RC(mostly
around 7), Linus would cut release. Then the release would be branched out
by Gerg KH, start stable maintenance work.

There is no merge between branches in Linux's case, no
master/develop/release branch. Records of same fix in different stable
trees are not maintained by merge record, but by cherry-pick.

I started this discussion is because I want to make sure community and
myself know exactly what we're heading to. I didn't know much about
git-flow, and I did have lots of question. I am sure most of the community
would have a better idea of how things work after these discussion.


> > they do have an strict code freeze.
>
> Well, sure, but the linux freeze is a very _different_ kind of code freeze
> to what cloudstack has been doing :). All that happens is the maintainers
> decide to stop merging things into their RC branches. The wider linux
> community doesn’t skip a beat. Heck, IMHO, if cloudstack were to adopt a
> more linux-like model that would be awesome…but you have to walk before you
> can run…for some reason I suspect this community is not ready to start
> rejecting commits because the first line of their message overruns 72
> characters…or because someone’s eclipse made unrelated whitespace changes…
>

I didn't see our community stopped as well. :)

I think up to this point, I am kind of understand what git-flow about to do
in general. And here are my remaining concerns:
1. The original model is pretty elegant, but when we need to maintain older
releases, which is not included in original model, it seems become more
complex.
2. I think we'd better need some control on release branch, rather than
leave it wide open for everyone. If we have an automation review/testing
system, I would agree to leave it open.
3. For most bug fixes, I didn't see a need for an separate branch for now.
And it's not in original git-flow model.

So far, if we would start a vote, I would vote +0.

BTW, back to the days I was working on it, I hadn't seen anyone use Eclipse
in Linux kernel...

--Sheng




>
> cheers,
>
>
> Leo
>
> [1] http://yarchive.net/comp/linux/git_merges_from_upstream.html
>     https://lkml.org/lkml/2008/5/21/351
>     http://lwn.net/Articles/328438/
>     …etc…

Re: [DISCUSS] git commit proces

[Leo Simons <LS...@schubergphilis.com>]

On Jul 31, 2014, at 12:55 AM, Sheng Yang <sh...@yasker.org> wrote:
> I suppose it would work like this:
> 1. In the original model, every release branch would be deleted after merge
> into develop and master branch. There is no release/4.4.1 or release/4.5
> branch.
> 2. Say we don't follow original model, when one release is released, you
> keep it. Say we have release/4.4 and release/4.5. And currently we're
> working on 4.7 which is develop branch, MASTER is 4.6.
> 3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1.
> 4. Then, conflict would happen when you merge release/4.4. branch to
> release/4.5. Since the version number changed to 4.4.1. You need to deal
> with version number conflict every time when merge to upper release.
> 5. Suppose you dealt with version number change. New release/4.5 would
> merge release/4.4 which merged release/4.3. Then you want to merge to
> master because there is a fix. Well, dealt with version number change
> conflict again.
> 6. Then, you would need to merge master to develop branch?
> 
> I am little worry about the conflict every time when merge happened. Seems
> version number conflict need to be dealt with everytime, and probably some
> other conflict. The conflict need to be solved may result in more
> error-prone situation.

Well, yes, _that_ would be horrible! :-)

Fortunately a merge only considers things that haven’t been merged before. If V means ‘bump version’, given

master -----------------------------------------
         \                 / \
r/4.5     V1---y----------V2  \
                \              \
r/4.6            \              V3--z-----------
                  \                /
fix                x---------------

because V1 is an ancestor of V3, when you merge x into r/4.6, git knows not to consider V1 commit again. It knows it only has to consider x. There is no conflict due to V1 or V2 at z. If you would do this

master ------------------------------------------
         \      \   /
r/4.5     V1-----\-V2----------------------------
                  \    \         \
r/4.6              V3---\-----z——-\----------z2--
                         \   /     \        /
fix                       x—-       \      /
                                     \    /
fix2                                  x2--

you will have a merge conflict once, at spot z, where you will have to resolve the conflict created by having conflicting ancestors V2 and V3. But you won’t have to deal with it at spot z2, since git will remember you already resolved that conflict before.

As long as you merge, instead of cherry-pick.

>> For example, the linux kernel has at least two active minor releases at
>> any given time, and many more minor releases and forks going on at that
>> same time, with hundreds (thousands?) of active developers, and even _they_
>> don’t need freezes. Instead the power is in their choices of what they do
>> and do not
> 
> I've worked on Linux kernel for years,

If you have experience with linux’ approach, I’d suggest you just look at git-flow as a massively simplified version of roughly that, which is easier to get into, something to hold on to while you develop experience and then good judgement [1] of when/what/where to merge. A reasonable starting point. Also, now I _really_ don’t understand why we have to have this discussion :)

> they do have an strict code freeze.

Well, sure, but the linux freeze is a very _different_ kind of code freeze to what cloudstack has been doing :). All that happens is the maintainers decide to stop merging things into their RC branches. The wider linux community doesn’t skip a beat. Heck, IMHO, if cloudstack were to adopt a more linux-like model that would be awesome…but you have to walk before you can run…for some reason I suspect this community is not ready to start rejecting commits because the first line of their message overruns 72 characters…or because someone’s eclipse made unrelated whitespace changes…


cheers,


Leo

[1] http://yarchive.net/comp/linux/git_merges_from_upstream.html
    https://lkml.org/lkml/2008/5/21/351
    http://lwn.net/Articles/328438/
    …etc…

Re: [DISCUSS] git commit proces

[Sheng Yang <sh...@yasker.org>]

On Wed, Jul 30, 2014 at 1:21 AM, Leo Simons <LS...@schubergphilis.com>
wrote:

> On Jul 30, 2014, at 1:14 AM, Sheng Yang <sh...@yasker.org> wrote:
> > The issue with current development process?
> > 1. Cherry-pick is needed for RM to choose stable fix commit after code
> > freeze to enforce quality.
> > 2. Bug fix to current release branch need to be checked in both release
> > branch and MASTER.
> > 3. I believe there would be more. Please comment.
>
> 4. where commits need to go is dependent on what phase of the release
> process you’re in, which requires sync. For example, if you’re working on a
> bug fix against 4.4 but then that is frozen you have to rebase against
> 4.4-forward. If you are doing this work on a public feature branch you have
> to re-cut your branch since you don’t want to rebase those.
>

In gitflow model, feature always branch out develop branch, not release
branch. In this case, 4.4 is release branch, 4.4-forward is develop
branch(for 4.4), both are descendence of old 4.4 branch the feature based
on, so I don't understand the difference here.


> 5. requires using synchronous process (freezes) to keep track of what is
> going on. This is not very healthy for a distributed project with
> contributors across many continents and companies. In contrast if you
> branch early and often you don’t freeze, you just avoid merging things that
> could destabilize things.
>

In gitflow model, feature branch is coming from develop branch, which is
also not stable I think? You need to live with unstable sometime.


> 6. does not allow looking into history to see what happened. I.e. if you
> were to cut a 4.5 branch from master, its code history is not at all the
> same or comparable (using git tools) to the code history of 4.4.
>

Yeah, this is an issue. In theory they should be the same, since every
fixes goes to where it should go.


> 7. reliant on error-prone human checking of merge status (looking if all
> cherries have been picked properly) rather than tool support (git
> confirming for you all changes from branch A made it to branch B)
>

git cherry provide that ability in this case.


> 8. default/naive checkouts of cloudstack tree result in a very unstable
> and sometimes unbuildable master
>

If we expect master to be stable, this is a problem. Though it's not
expected to be stable in our current model.


>
> The list goes on! But I don’t see why we should repeat all these things
> here when the internet is full of these kinds of discussions already, as
> are this mailing list’s archives…
>
> > 3. Code freeze: No such concept in the flow. Need to know how to guide
> the
> > check in.
>
> Mostly by discipline. Committers normally commit to develop and/or feature
> branches, and switch only to the release branch to commit very specific
> bugfixes. You can agree a policy (for example like Alena described) for how
> to make the decision what should and should not go on onto the release
> branch.
>

I don't quite believe in this. I believe self-discipline is not enough when
we facing something like release. I even don't like only one RM working as
gatekeeper. We should have all set of tools support from mandatory review
to automatic testing, and probably QA specific testing. In Linux kernel,
every commit would pass at least two person: subsystem maintainer and
Linus, before enter RC. Of course there would be more people reviewing in
the mailing list as well. But I think even now we trusted too much on
self-discipline, result in issues in code quality.


>
> > 5. The original post didn't mention minor release. I suppose it may work
> > like this:
> >
> >   1. Branch out MASTER to 4.4 release
> >   2. Any bug fixes happened on 4.4 need to be merge to MASTER.
> >   3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's
> needed
> >   is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can we
> fix
> >   it in develop branch(which meant for test)? I can't see how you can
> avoid
> >   cherry-pick or extra commit if you want to have a maintenance release.
>
> There will be extra commits, but they will be merge commits. I.e.
>
> master                 ------4.3-----4.4--------------x4.5
>                                    |  \              /
> release/4.4.1                        |   \——----x--   /
>                                      |    \    /     /
> bugfix/CLOUDSTACK-1234               |     \—x/     /
>                                      |      \ \    /
> release/4.5                          |       \—x—-/
>                                      |          \ \
> develop                --------------y-----------x---------
>
> the commit x will always be there exactly once, it will get exactly one
> sha1 checksum and one spot in the git index, and git will forever remember
> all the different branches that include x.
>
> On some of those branches there may be merge commits (if you explicitly
> chose to have them, or if git decided they were needed) following x, to
> record the merges that were done.
>
> You can basically always do this as long as you *start your fix on the
> oldest branch* that you want to fix. So if you want to fix a bug in 4.4.1,
> 4.5.0, and all future releases, you develop the fix against the 4.4.1
> branch, and then merge from there to the 4.5 branch, and then merge from
> there to the develop branch.
>
> This works very well with git because it remembers the complete history of
> everything (if you don’t cherry-pick). I.e. if commit y is the last commit
> that is in common between master and develop, when it becomes time
> to merge x to develop, git will traverse the whole history of x until it
> finds y, then consider the situation from there. As long as you don’t
> cherry-pick, git can do this logic provably correctly looking mostly at
> sha1 commit ids.
>


I suppose it would work like this:
1. In the original model, every release branch would be deleted after merge
into develop and master branch. There is no release/4.4.1 or release/4.5
branch.
2. Say we don't follow original model, when one release is released, you
keep it. Say we have release/4.4 and release/4.5. And currently we're
working on 4.7 which is develop branch, MASTER is 4.6.
3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1.
4. Then, conflict would happen when you merge release/4.4. branch to
release/4.5. Since the version number changed to 4.4.1. You need to deal
with version number conflict every time when merge to upper release.
5. Suppose you dealt with version number change. New release/4.5 would
merge release/4.4 which merged release/4.3. Then you want to merge to
master because there is a fix. Well, dealt with version number change
conflict again.
6. Then, you would need to merge master to develop branch?

I am little worry about the conflict every time when merge happened. Seems
version number conflict need to be dealt with everytime, and probably some
other conflict. The conflict need to be solved may result in more
error-prone situation.

And in this model, one error in the old release's fix would have chain
effect to all the newer stable release, which make me a little concerned.


>
> > Before realizing the maintenance release issue, I was quite like this
> > approach, which means no more duplicate work need to be done. But sadly
> the
> > most usage for cherry-pick is due to we need to fix multiple versions.
> > Current I can't see how utilize gitflow or git merge would solve the
> issue.
> > Is there a better way to handle this?
>
> I hope the above helps. If it doesn’t, what I recommend to you (and anyone
> else having these kinds of questions is) to just _try it_. These kinds of
> conversations are very hard, and the diagrams can be confusing, but, when
> you’re actually doing the work and typing in the commands, it is really
> much much easier to follow than the discussion itself. If you’ve never
> worked on a many-branches git project before you’re in for a treat: the
> first time you do what you think is a complex merge, and git just does it
> for you, it feels like magic :-)
>
> > And, I think gitflow model doesn't have "code freeze" period which we can
> > have a gatekeeper to keep the quality. So, if we want to compare to
> gitflow
> > model, we would simply skip "code freeze" stage in our current process. I
> > don't think it make much sense.
>
> You know, you could keep the concept of a freeze, git-flow doesn’t mind.
> The way it would look is that after a release branch freeze, all further
> bugfixes to that release would be required to be on their own bug fix
> branches, and the gatekeeper(s) would be the only ones merging those into
> the release branch.
>
> But, generally, teams find that increased discipline in what&how to commit
> combined with a solid branch workflow means they don’t need such
> heavy-handed methods. It’s one of the true joys of distributed version
> control to let go of things like this!
>
> For example, the linux kernel has at least two active minor releases at
> any given time, and many more minor releases and forks going on at that
> same time, with hundreds (thousands?) of active developers, and even _they_
> don’t need freezes. Instead the power is in their choices of what they do
> and do not
>

I've worked on Linux kernel for years, they do have an strict code freeze.

Whenever Linus close the merge window and cut RC1, it's in code freeze.
They have only stage of one freeze. The ultimate gatekeeper Linus, and
subsystem maintainers would keep everything under their eyes. Unless you're
maintainer who is able to let Linus pull your tree directly, your commit
need to be approved twice - by subsystem maintainer and Linus, along with
the big community scrutinize your work. The things happened from time to
time that subsystem maintainer want to smugger something to in RC
stage(often small enough but not strictly a bug fix) but somehow spotted by
Linus, then you know what would happen.

The minor release of Linux is different from mainstream development. Greg
KH would maintain all these stable releases in separate branches. He would
answer to pull requests for stable release from subsystem maintainers,
which work already passed subsystem maintainer and community's scrutiny.
Even though, no flow/merge would across the stable releases. There are
thousands of active developers in Linux kernel community, only subsystem
maintainers have git permission, everyone else have to submit patch through
mail.

So I don't understand why you said Linux doesn't need freeze.


>
> > 3. How about the workload for merge between release and develop branch?
> It
> > would be quite frequently.
>
> Yes it would be frequent. Exactly because it is frequent, it should be
> relatively effortless, no more work than 'git pull'. (after all, git pull
> is nothing more than 'git fetch' followed by 'git merge'...you do lots of
> merging already...)
>

git pull is on the same code base. I hope it would be no more work that git
pull.

--Sheng

>
> > Btw, that no-cherry-picking(
> > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html)
> article
> > has a mistake in it. The result it's showing in fact shows that git
> cherry
> > -v DID recongize the cherry-pickup result by showing "-" in front of the
> > commit. I guess git is smart enough to know that.
> ...
> >       The equivalence test is based on the diff, after removing
> whitespace
> > and line numbers. git-cherry therefore detects when commits have been
> > "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).
>
> Yeah, it’s pretty powerful :-)
>
> Unfortunately comparing the diff is not nearly as powerful as comparing
> the sha1 ID. Those commit ids don’t just point at a diff, they point at a
> _commit_, which is that diff *as applied to all the history that came
> before*. With that extra detail, you can do much more powerful things, and
> git can do much more powerful things for you.
>
>
> cheers,
>
>
> Leo
>
>

Re: [DISCUSS] git commit proces

[Leo Simons <LS...@schubergphilis.com>]

On Jul 30, 2014, at 1:14 AM, Sheng Yang <sh...@yasker.org> wrote:
> The issue with current development process?
> 1. Cherry-pick is needed for RM to choose stable fix commit after code
> freeze to enforce quality.
> 2. Bug fix to current release branch need to be checked in both release
> branch and MASTER.
> 3. I believe there would be more. Please comment.

4. where commits need to go is dependent on what phase of the release process you’re in, which requires sync. For example, if you’re working on a bug fix against 4.4 but then that is frozen you have to rebase against 4.4-forward. If you are doing this work on a public feature branch you have to re-cut your branch since you don’t want to rebase those.
5. requires using synchronous process (freezes) to keep track of what is going on. This is not very healthy for a distributed project with contributors across many continents and companies. In contrast if you branch early and often you don’t freeze, you just avoid merging things that could destabilize things.
6. does not allow looking into history to see what happened. I.e. if you were to cut a 4.5 branch from master, its code history is not at all the same or comparable (using git tools) to the code history of 4.4.
7. reliant on error-prone human checking of merge status (looking if all cherries have been picked properly) rather than tool support (git confirming for you all changes from branch A made it to branch B)
8. default/naive checkouts of cloudstack tree result in a very unstable and sometimes unbuildable master

The list goes on! But I don’t see why we should repeat all these things here when the internet is full of these kinds of discussions already, as are this mailing list’s archives…

> 3. Code freeze: No such concept in the flow. Need to know how to guide the
> check in.

Mostly by discipline. Committers normally commit to develop and/or feature branches, and switch only to the release branch to commit very specific bugfixes. You can agree a policy (for example like Alena described) for how to make the decision what should and should not go on onto the release branch.

> 5. The original post didn't mention minor release. I suppose it may work
> like this:
> 
>   1. Branch out MASTER to 4.4 release
>   2. Any bug fixes happened on 4.4 need to be merge to MASTER.
>   3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's needed
>   is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can we fix
>   it in develop branch(which meant for test)? I can't see how you can avoid
>   cherry-pick or extra commit if you want to have a maintenance release.

There will be extra commits, but they will be merge commits. I.e.

master                 ------4.3-----4.4--------------x4.5
                                     |  \              /
release/4.4.1                        |   \——----x--   /
                                     |    \    /     /
bugfix/CLOUDSTACK-1234               |     \—x/     /
                                     |      \ \    /
release/4.5                          |       \—x—-/
                                     |          \ \
develop                --------------y-----------x---------

the commit x will always be there exactly once, it will get exactly one sha1 checksum and one spot in the git index, and git will forever remember all the different branches that include x.

On some of those branches there may be merge commits (if you explicitly chose to have them, or if git decided they were needed) following x, to record the merges that were done.

You can basically always do this as long as you *start your fix on the oldest branch* that you want to fix. So if you want to fix a bug in 4.4.1, 4.5.0, and all future releases, you develop the fix against the 4.4.1 branch, and then merge from there to the 4.5 branch, and then merge from there to the develop branch.

This works very well with git because it remembers the complete history of everything (if you don’t cherry-pick). I.e. if commit y is the last commit that is in common between master and develop, when it becomes time
to merge x to develop, git will traverse the whole history of x until it finds y, then consider the situation from there. As long as you don’t cherry-pick, git can do this logic provably correctly looking mostly at sha1 commit ids.

> Before realizing the maintenance release issue, I was quite like this
> approach, which means no more duplicate work need to be done. But sadly the
> most usage for cherry-pick is due to we need to fix multiple versions.
> Current I can't see how utilize gitflow or git merge would solve the issue.
> Is there a better way to handle this?

I hope the above helps. If it doesn’t, what I recommend to you (and anyone else having these kinds of questions is) to just _try it_. These kinds of conversations are very hard, and the diagrams can be confusing, but, when you’re actually doing the work and typing in the commands, it is really much much easier to follow than the discussion itself. If you’ve never worked on a many-branches git project before you’re in for a treat: the first time you do what you think is a complex merge, and git just does it for you, it feels like magic :-)

> And, I think gitflow model doesn't have "code freeze" period which we can
> have a gatekeeper to keep the quality. So, if we want to compare to gitflow
> model, we would simply skip "code freeze" stage in our current process. I
> don't think it make much sense.

You know, you could keep the concept of a freeze, git-flow doesn’t mind. The way it would look is that after a release branch freeze, all further bugfixes to that release would be required to be on their own bug fix branches, and the gatekeeper(s) would be the only ones merging those into the release branch.

But, generally, teams find that increased discipline in what&how to commit combined with a solid branch workflow means they don’t need such heavy-handed methods. It’s one of the true joys of distributed version control to let go of things like this!

For example, the linux kernel has at least two active minor releases at any given time, and many more minor releases and forks going on at that same time, with hundreds (thousands?) of active developers, and even _they_ don’t need freezes. Instead the power is in their choices of what they do and do not

> 3. How about the workload for merge between release and develop branch? It
> would be quite frequently.

Yes it would be frequent. Exactly because it is frequent, it should be relatively effortless, no more work than 'git pull'. (after all, git pull is nothing more than 'git fetch' followed by 'git merge'...you do lots of merging already...)

> Btw, that no-cherry-picking(
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html) article
> has a mistake in it. The result it's showing in fact shows that git cherry
> -v DID recongize the cherry-pickup result by showing "-" in front of the
> commit. I guess git is smart enough to know that.
...
>       The equivalence test is based on the diff, after removing whitespace
> and line numbers. git-cherry therefore detects when commits have been
> "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).

Yeah, it’s pretty powerful :-)

Unfortunately comparing the diff is not nearly as powerful as comparing the sha1 ID. Those commit ids don’t just point at a diff, they point at a _commit_, which is that diff *as applied to all the history that came before*. With that extra detail, you can do much more powerful things, and git can do much more powerful things for you.


cheers,


Leo

Re: [DISCUSS] git commit proces

[Sheng Yang <sh...@yasker.org>]

On Wed, Jul 30, 2014 at 12:37 AM, Sebastien Goasguen <ru...@gmail.com>
wrote:

>
> On Jul 29, 2014, at 8:40 PM, Sheng Yang <sh...@yasker.org> wrote:
>
> > And talking about to achieve good code quality, I think compulsive review
> > and testing through some kind of automation system is much more helpful.
> >
> > --Sheng
> >
>
> This new git workflow is not directly about good code quality, as a wise
> man told me the other day "crap gets in, crap gets out, not matter what you
> do with git".
>
> IMHO, code quality will indeed be fixed with more reviews and a CI
> pipeline, but it will also mean accepting only patches that have tests with
> it.
> So no unittests, no integration tests, no commit. But I think we are way
> far from this.
>
> There is currently a BVT automatic testing infra proposal on the table
> from citrix, but this needs to be on ASF infra, and it seems no-one has
> wanted to push this proposal much further.
>

In Citrix, we're actively working on enforce review and testing during our
commit process, trying to close the gap. Inside our company, we're planning
to do exactly "no review, no testing, no commit". And we're working on make
that process easy to developers. But last time when I brought up idea about
enforcing review and testing by using gerrit or other similar automation
tools, seems community didn't care much about it.

The testing is limited by resource so far, but at least mandatory reviewing
is something we should work on as I thought.


>
> Starting with a better git workflow should bring us up to standard methods
> of developing with git.
>
> x.y-forward has been a mess, calling for [MERGE] request for new features
> has been totally neglected by developers, folks fix a bug in master but
> don't care to check if it applies on other branches and don't fix it there.
> Or maybe they fix on a release branch and don't fix on master.
>

> The end result of this bad practice is this:
>
> -I have personally 0% confidence that a bug fixed somewhere is fixed
> everywhere (it gets even worse when you bring in bad JIRA practices with
> bugs being closed when they are not closed).
>

This is my biggest concern as well. I hate doing fix for all the branches
though I have to do it every time. I am more than willing to get this
solved. But I haven't clear how gitflow model would able to handle multiple
maintenance version issue. If this can be solved elegantly that would be
great.


> -We have quite a bit of regressions
> -Our new releases are pretty much different/diverging products
> -We don't know what's in a future release (exemplified by difficulty for
> RM to get list of new features)
> -And more importantly we don't have a stable branch.
>
> This proposed git workflow would give us:
>
> -A stable branch (master). You checkout master get a shippable product.
> Very few commits to master are made, development is moved to 'develop'
> branch. Only hot fixes of current release get merged in master (which means
> it's still a shippable product). I am in favor of being draconian with
> this, and I am sure we would see a lot of reverts in the first weeks of
> adopting this workflow. But we need to stabilize master.
>

I don't against a stable master idea. I think it's good to have, and anyway
we have stable previous release and relatively stable developing branch
now. So if we want to call it "master" or not, I don't think it's very
important.

>
> -Everyone works on branches and knows where to merge. Developers will know
> where they branched from and where they need to merge into. This will also
> mean that history, tracking, reverting  should also be easier. (personally
> I am not entirely against cherry-picks and I could live with some minimal
> amount done by the RM, but they problem with cherry picking right now is
> with the way we apply patches to various branches…untraceable).


Can't agree more on this, though I am still trying understand how this can
be achieved by the new model.

>
> -This will also mean that our release branches are clearly defined and a
> RM can actually pick features to merge into a release, but these release
> branches should/will be merged into master instead of being abandoned like
> we do now.
>

I think release branch would still needed if we want to release maintenance
release.

>
> -Now about minor releases. Say we release 4.5, the tag is in master (not
> on a release branch), we have a few hot fixes that John Smith says are very
> important. Those hot fixes get merged into master (and into develop), we
> then call a vote on the latest master (e.g 4.5.1-tentative) if it passes
> tag it (4.5.1) and we have a new minor release without new features. Master
> is stable.
>

Yes. But how about 4.4.1? Master only contained the latest release. What
about previous one?

--Sheng


>
> The big advantage I see with this is that our release process should be
> much easier and we will have one continuous shippable product, instead of
> real forks.
>
> -sebastien
>
>
> >
> > On Tue, Jul 29, 2014 at 4:14 PM, Sheng Yang <sh...@yasker.org> wrote:
> >
> >> Hi Leo,
> >>
> >> I am afraid the answer is too generic. We'd better look into details to
> >> see what's the exactly problem.
> >>
> >> So I am trying to sort it out.
> >>
> >> The first question we want to ask is:
> >>
> >> A. What's current develop process?
> >>
> >> I don't know where is it documented, but as I know, it works like
> >> this(please correct me if I am wrong)
> >>
> >> 1. Development happen on MASTER first.
> >>
> >>   - Can merge feature branch.
> >>
> >>
> >> 2. Feature freeze, cut staging release branch. No major feature can be
> >> checked in.
> >>
> >>   - Say we would release 4.4, then RM create branch 4.4.
> >>   - All the major feature would be worked on MASTER.
> >>   - All the fix for 4.4 need to be applied on 4.4, and MASTER.
> >>
> >> 3. Code freeze. Branch out staging tree, try to enforce quality.
> >>
> >>   - RM branch 4.4-forward from 4.4 branch.
> >>   - 4.4 branch freezed, only allow to be checked in by RM.
> >>   - Any 4.4 bug fix need to be applied on 4.4-forward, and after all the
> >>   test and check, developer would ask RM to cherry-pick it to 4.4
> branch. RM
> >>   would be the gate keeper for 4.4 branch.
> >>   - In the meanwhile, MASTER would still serve as unstable tree for next
> >>   release.
> >>
> >> 4. Release. Release branch would be release.
> >>
> >>   - Release based on branch 4.4, then dropped branch 4.4
> >>   - 4.4-forward branch would be rename to 4.4, and continue to serving
> >>   as release base for 4.4.1 release.
> >>
> >> 5. For release of 4.4.1 and after. Repeat step 3 and 4(probably not
> >> strictly in fact). For release of 4.5. Repeat steps 1-4.
> >>
> >> The issue with current development process?
> >> 1. Cherry-pick is needed for RM to choose stable fix commit after code
> >> freeze to enforce quality.
> >> 2. Bug fix to current release branch need to be checked in both release
> >> branch and MASTER.
> >> 3. I believe there would be more. Please comment.
> >>
> >> B. What's the purposed process.
> >>
> >> The idea of gitflow is from
> >> http://nvie.com/posts/a-successful-git-branching-model/
> >>
> >> To my understanding, compare to our current process, it suggested:
> >> 1. Develop branched out from MASTER branch, which would be what's
> majority
> >> of work happens on.
> >>
> >>   - Develop branch can merge feature branch.
> >>   - MASTER would always be stable.
> >>
> >> 2. Feature freeze: Create Release branch: When ready to release, branch
> >> out Release branch from Develop branch.
> >>
> >>   - Release bug fixes only happen on Release branch.
> >>   - Develop branch need to constantly merge Release branch for latest
> >>   bug fixes.
> >>   - In the meanwhile, Develop branch can still merge feature branch.
> >>
> >> 3. Code freeze: No such concept in the flow. Need to know how to guide
> the
> >> check in.
> >>
> >> 4. Release. Release branch merge into MASTER. Tagged and release.
> >>
> >> 5. The original post didn't mention minor release. I suppose it may work
> >> like this:
> >>
> >>   1. Branch out MASTER to 4.4 release
> >>   2. Any bug fixes happened on 4.4 need to be merge to MASTER.
> >>   3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's
> >>   needed is MASTER merged 4.5 which merged 4.4 which merged 4.3. And
> how can
> >>   we fix it in develop branch(which meant for test)? I can't see how
> you can
> >>   avoid cherry-pick or extra commit if you want to have a maintenance
> release.
> >>
> >> Before realizing the maintenance release issue, I was quite like this
> >> approach, which means no more duplicate work need to be done. But sadly
> the
> >> most usage for cherry-pick is due to we need to fix multiple versions.
> >> Current I can't see how utilize gitflow or git merge would solve the
> issue.
> >> Is there a better way to handle this?
> >>
> >> And, I think gitflow model doesn't have "code freeze" period which we
> can
> >> have a gatekeeper to keep the quality. So, if we want to compare to
> gitflow
> >> model, we would simply skip "code freeze" stage in our current process.
> I
> >> don't think it make much sense.
> >>
> >> I think all gitflow has is eliminate one time check in for fixing
> current
> >> release branch(we need to check in both release branch and master
> branch)
> >> compare to our current process, but:
> >> 1. How would it handle maintenance release?
> >> 2. How would code freeze work?
> >> 3. How about the workload for merge between release and develop branch?
> It
> >> would be quite frequently.
> >>
> >> As a developer, I hate multiple branches check in as much as anyone
> else,
> >> probably even more. But I am not sure gitflow can help us here.
> >>
> >> Btw, that no-cherry-picking(
> >> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html)
> article
> >> has a mistake in it. The result it's showing in fact shows that git
> cherry
> >> -v DID recongize the cherry-pickup result by showing "-" in front of the
> >> commit. I guess git is smart enough to know that.
> >>
> >> Here is the manual of git-cherry.
> >>
> >> SYNOPSIS
> >>       git cherry [-v] [<upstream> [<head> [<limit>]]]
> >>
> >> DESCRIPTION
> >>       Determine whether there are commits in <head>..<upstream> that are
> >> equivalent to those in the range <limit>..<head>.
> >>
> >>       The equivalence test is based on the diff, after removing
> >> whitespace and line numbers. git-cherry therefore detects when commits
> have
> >> been "copied" by means of git-cherry-pick(1), git-am(1) or
> git-rebase(1).
> >>
> >>       Outputs the SHA1 of every commit in <limit>..<head>, prefixed with
> >> - for commits that have an equivalent in <upstream>, and + for commits
> that
> >> do not.
> >>
> >> --Sheng
> >>
> >> On Tue, Jul 29, 2014 at 12:52 AM, Leo Simons <
> LSimons@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
> >>>
> >>>
> >>
>
>

Re: [DISCUSS] git commit proces

[Sebastien Goasguen <ru...@gmail.com>]

On Jul 29, 2014, at 8:40 PM, Sheng Yang <sh...@yasker.org> wrote:

> And talking about to achieve good code quality, I think compulsive review
> and testing through some kind of automation system is much more helpful.
> 
> --Sheng
> 

This new git workflow is not directly about good code quality, as a wise man told me the other day "crap gets in, crap gets out, not matter what you do with git".

IMHO, code quality will indeed be fixed with more reviews and a CI pipeline, but it will also mean accepting only patches that have tests with it.
So no unittests, no integration tests, no commit. But I think we are way far from this.

There is currently a BVT automatic testing infra proposal on the table from citrix, but this needs to be on ASF infra, and it seems no-one has wanted to push this proposal much further.

Starting with a better git workflow should bring us up to standard methods of developing with git.

x.y-forward has been a mess, calling for [MERGE] request for new features has been totally neglected by developers, folks fix a bug in master but don't care to check if it applies on other branches and don't fix it there. Or maybe they fix on a release branch and don't fix on master.

The end result of this bad practice is this:

-I have personally 0% confidence that a bug fixed somewhere is fixed everywhere (it gets even worse when you bring in bad JIRA practices with bugs being closed when they are not closed).
-We have quite a bit of regressions
-Our new releases are pretty much different/diverging products
-We don't know what's in a future release (exemplified by difficulty for RM to get list of new features)
-And more importantly we don't have a stable branch.

This proposed git workflow would give us:

-A stable branch (master). You checkout master get a shippable product. Very few commits to master are made, development is moved to 'develop' branch. Only hot fixes of current release get merged in master (which means it's still a shippable product). I am in favor of being draconian with this, and I am sure we would see a lot of reverts in the first weeks of adopting this workflow. But we need to stabilize master.

-Everyone works on branches and knows where to merge. Developers will know where they branched from and where they need to merge into. This will also mean that history, tracking, reverting  should also be easier. (personally I am not entirely against cherry-picks and I could live with some minimal amount done by the RM, but they problem with cherry picking right now is with the way we apply patches to various branches…untraceable).

-This will also mean that our release branches are clearly defined and a RM can actually pick features to merge into a release, but these release branches should/will be merged into master instead of being abandoned like we do now.

-Now about minor releases. Say we release 4.5, the tag is in master (not on a release branch), we have a few hot fixes that John Smith says are very important. Those hot fixes get merged into master (and into develop), we then call a vote on the latest master (e.g 4.5.1-tentative) if it passes tag it (4.5.1) and we have a new minor release without new features. Master is stable.

The big advantage I see with this is that our release process should be much easier and we will have one continuous shippable product, instead of real forks.

-sebastien


> 
> On Tue, Jul 29, 2014 at 4:14 PM, Sheng Yang <sh...@yasker.org> wrote:
> 
>> Hi Leo,
>> 
>> I am afraid the answer is too generic. We'd better look into details to
>> see what's the exactly problem.
>> 
>> So I am trying to sort it out.
>> 
>> The first question we want to ask is:
>> 
>> A. What's current develop process?
>> 
>> I don't know where is it documented, but as I know, it works like
>> this(please correct me if I am wrong)
>> 
>> 1. Development happen on MASTER first.
>> 
>>   - Can merge feature branch.
>> 
>> 
>> 2. Feature freeze, cut staging release branch. No major feature can be
>> checked in.
>> 
>>   - Say we would release 4.4, then RM create branch 4.4.
>>   - All the major feature would be worked on MASTER.
>>   - All the fix for 4.4 need to be applied on 4.4, and MASTER.
>> 
>> 3. Code freeze. Branch out staging tree, try to enforce quality.
>> 
>>   - RM branch 4.4-forward from 4.4 branch.
>>   - 4.4 branch freezed, only allow to be checked in by RM.
>>   - Any 4.4 bug fix need to be applied on 4.4-forward, and after all the
>>   test and check, developer would ask RM to cherry-pick it to 4.4 branch. RM
>>   would be the gate keeper for 4.4 branch.
>>   - In the meanwhile, MASTER would still serve as unstable tree for next
>>   release.
>> 
>> 4. Release. Release branch would be release.
>> 
>>   - Release based on branch 4.4, then dropped branch 4.4
>>   - 4.4-forward branch would be rename to 4.4, and continue to serving
>>   as release base for 4.4.1 release.
>> 
>> 5. For release of 4.4.1 and after. Repeat step 3 and 4(probably not
>> strictly in fact). For release of 4.5. Repeat steps 1-4.
>> 
>> The issue with current development process?
>> 1. Cherry-pick is needed for RM to choose stable fix commit after code
>> freeze to enforce quality.
>> 2. Bug fix to current release branch need to be checked in both release
>> branch and MASTER.
>> 3. I believe there would be more. Please comment.
>> 
>> B. What's the purposed process.
>> 
>> The idea of gitflow is from
>> http://nvie.com/posts/a-successful-git-branching-model/
>> 
>> To my understanding, compare to our current process, it suggested:
>> 1. Develop branched out from MASTER branch, which would be what's majority
>> of work happens on.
>> 
>>   - Develop branch can merge feature branch.
>>   - MASTER would always be stable.
>> 
>> 2. Feature freeze: Create Release branch: When ready to release, branch
>> out Release branch from Develop branch.
>> 
>>   - Release bug fixes only happen on Release branch.
>>   - Develop branch need to constantly merge Release branch for latest
>>   bug fixes.
>>   - In the meanwhile, Develop branch can still merge feature branch.
>> 
>> 3. Code freeze: No such concept in the flow. Need to know how to guide the
>> check in.
>> 
>> 4. Release. Release branch merge into MASTER. Tagged and release.
>> 
>> 5. The original post didn't mention minor release. I suppose it may work
>> like this:
>> 
>>   1. Branch out MASTER to 4.4 release
>>   2. Any bug fixes happened on 4.4 need to be merge to MASTER.
>>   3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's
>>   needed is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can
>>   we fix it in develop branch(which meant for test)? I can't see how you can
>>   avoid cherry-pick or extra commit if you want to have a maintenance release.
>> 
>> Before realizing the maintenance release issue, I was quite like this
>> approach, which means no more duplicate work need to be done. But sadly the
>> most usage for cherry-pick is due to we need to fix multiple versions.
>> Current I can't see how utilize gitflow or git merge would solve the issue.
>> Is there a better way to handle this?
>> 
>> And, I think gitflow model doesn't have "code freeze" period which we can
>> have a gatekeeper to keep the quality. So, if we want to compare to gitflow
>> model, we would simply skip "code freeze" stage in our current process. I
>> don't think it make much sense.
>> 
>> I think all gitflow has is eliminate one time check in for fixing current
>> release branch(we need to check in both release branch and master branch)
>> compare to our current process, but:
>> 1. How would it handle maintenance release?
>> 2. How would code freeze work?
>> 3. How about the workload for merge between release and develop branch? It
>> would be quite frequently.
>> 
>> As a developer, I hate multiple branches check in as much as anyone else,
>> probably even more. But I am not sure gitflow can help us here.
>> 
>> Btw, that no-cherry-picking(
>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html) article
>> has a mistake in it. The result it's showing in fact shows that git cherry
>> -v DID recongize the cherry-pickup result by showing "-" in front of the
>> commit. I guess git is smart enough to know that.
>> 
>> Here is the manual of git-cherry.
>> 
>> SYNOPSIS
>>       git cherry [-v] [<upstream> [<head> [<limit>]]]
>> 
>> DESCRIPTION
>>       Determine whether there are commits in <head>..<upstream> that are
>> equivalent to those in the range <limit>..<head>.
>> 
>>       The equivalence test is based on the diff, after removing
>> whitespace and line numbers. git-cherry therefore detects when commits have
>> been "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).
>> 
>>       Outputs the SHA1 of every commit in <limit>..<head>, prefixed with
>> - for commits that have an equivalent in <upstream>, and + for commits that
>> do not.
>> 
>> --Sheng
>> 
>> On Tue, Jul 29, 2014 at 12:52 AM, Leo Simons <LS...@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
>>> 
>>> 
>> 

Re: [DISCUSS] git commit proces

[Sheng Yang <sh...@yasker.org>]

And talking about to achieve good code quality, I think compulsive review
and testing through some kind of automation system is much more helpful.

--Sheng


On Tue, Jul 29, 2014 at 4:14 PM, Sheng Yang <sh...@yasker.org> wrote:

> Hi Leo,
>
> I am afraid the answer is too generic. We'd better look into details to
> see what's the exactly problem.
>
> So I am trying to sort it out.
>
> The first question we want to ask is:
>
> A. What's current develop process?
>
> I don't know where is it documented, but as I know, it works like
> this(please correct me if I am wrong)
>
> 1. Development happen on MASTER first.
>
>    - Can merge feature branch.
>
>
> 2. Feature freeze, cut staging release branch. No major feature can be
> checked in.
>
>    - Say we would release 4.4, then RM create branch 4.4.
>    - All the major feature would be worked on MASTER.
>    - All the fix for 4.4 need to be applied on 4.4, and MASTER.
>
> 3. Code freeze. Branch out staging tree, try to enforce quality.
>
>    - RM branch 4.4-forward from 4.4 branch.
>    - 4.4 branch freezed, only allow to be checked in by RM.
>    - Any 4.4 bug fix need to be applied on 4.4-forward, and after all the
>    test and check, developer would ask RM to cherry-pick it to 4.4 branch. RM
>    would be the gate keeper for 4.4 branch.
>    - In the meanwhile, MASTER would still serve as unstable tree for next
>    release.
>
> 4. Release. Release branch would be release.
>
>    - Release based on branch 4.4, then dropped branch 4.4
>    - 4.4-forward branch would be rename to 4.4, and continue to serving
>    as release base for 4.4.1 release.
>
> 5. For release of 4.4.1 and after. Repeat step 3 and 4(probably not
> strictly in fact). For release of 4.5. Repeat steps 1-4.
>
> The issue with current development process?
> 1. Cherry-pick is needed for RM to choose stable fix commit after code
> freeze to enforce quality.
> 2. Bug fix to current release branch need to be checked in both release
> branch and MASTER.
> 3. I believe there would be more. Please comment.
>
> B. What's the purposed process.
>
> The idea of gitflow is from
> http://nvie.com/posts/a-successful-git-branching-model/
>
> To my understanding, compare to our current process, it suggested:
> 1. Develop branched out from MASTER branch, which would be what's majority
> of work happens on.
>
>    - Develop branch can merge feature branch.
>    - MASTER would always be stable.
>
> 2. Feature freeze: Create Release branch: When ready to release, branch
> out Release branch from Develop branch.
>
>    - Release bug fixes only happen on Release branch.
>    - Develop branch need to constantly merge Release branch for latest
>    bug fixes.
>    - In the meanwhile, Develop branch can still merge feature branch.
>
> 3. Code freeze: No such concept in the flow. Need to know how to guide the
> check in.
>
> 4. Release. Release branch merge into MASTER. Tagged and release.
>
> 5. The original post didn't mention minor release. I suppose it may work
> like this:
>
>    1. Branch out MASTER to 4.4 release
>    2. Any bug fixes happened on 4.4 need to be merge to MASTER.
>    3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's
>    needed is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can
>    we fix it in develop branch(which meant for test)? I can't see how you can
>    avoid cherry-pick or extra commit if you want to have a maintenance release.
>
> Before realizing the maintenance release issue, I was quite like this
> approach, which means no more duplicate work need to be done. But sadly the
> most usage for cherry-pick is due to we need to fix multiple versions.
> Current I can't see how utilize gitflow or git merge would solve the issue.
> Is there a better way to handle this?
>
> And, I think gitflow model doesn't have "code freeze" period which we can
> have a gatekeeper to keep the quality. So, if we want to compare to gitflow
> model, we would simply skip "code freeze" stage in our current process. I
> don't think it make much sense.
>
> I think all gitflow has is eliminate one time check in for fixing current
> release branch(we need to check in both release branch and master branch)
> compare to our current process, but:
> 1. How would it handle maintenance release?
> 2. How would code freeze work?
> 3. How about the workload for merge between release and develop branch? It
> would be quite frequently.
>
> As a developer, I hate multiple branches check in as much as anyone else,
> probably even more. But I am not sure gitflow can help us here.
>
> Btw, that no-cherry-picking(
> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html) article
> has a mistake in it. The result it's showing in fact shows that git cherry
> -v DID recongize the cherry-pickup result by showing "-" in front of the
> commit. I guess git is smart enough to know that.
>
> Here is the manual of git-cherry.
>
> SYNOPSIS
>        git cherry [-v] [<upstream> [<head> [<limit>]]]
>
> DESCRIPTION
>        Determine whether there are commits in <head>..<upstream> that are
> equivalent to those in the range <limit>..<head>.
>
>        The equivalence test is based on the diff, after removing
> whitespace and line numbers. git-cherry therefore detects when commits have
> been "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).
>
>        Outputs the SHA1 of every commit in <limit>..<head>, prefixed with
> - for commits that have an equivalent in <upstream>, and + for commits that
> do not.
>
> --Sheng
>
> On Tue, Jul 29, 2014 at 12:52 AM, Leo Simons <LS...@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
>>
>>
>

Re: [DISCUSS] git commit proces

[Sheng Yang <sh...@yasker.org>]

Hi Leo,

I am afraid the answer is too generic. We'd better look into details to see
what's the exactly problem.

So I am trying to sort it out.

The first question we want to ask is:

A. What's current develop process?

I don't know where is it documented, but as I know, it works like
this(please correct me if I am wrong)

1. Development happen on MASTER first.

   - Can merge feature branch.


2. Feature freeze, cut staging release branch. No major feature can be
checked in.

   - Say we would release 4.4, then RM create branch 4.4.
   - All the major feature would be worked on MASTER.
   - All the fix for 4.4 need to be applied on 4.4, and MASTER.

3. Code freeze. Branch out staging tree, try to enforce quality.

   - RM branch 4.4-forward from 4.4 branch.
   - 4.4 branch freezed, only allow to be checked in by RM.
   - Any 4.4 bug fix need to be applied on 4.4-forward, and after all the
   test and check, developer would ask RM to cherry-pick it to 4.4 branch. RM
   would be the gate keeper for 4.4 branch.
   - In the meanwhile, MASTER would still serve as unstable tree for next
   release.

4. Release. Release branch would be release.

   - Release based on branch 4.4, then dropped branch 4.4
   - 4.4-forward branch would be rename to 4.4, and continue to serving as
   release base for 4.4.1 release.

5. For release of 4.4.1 and after. Repeat step 3 and 4(probably not
strictly in fact). For release of 4.5. Repeat steps 1-4.

The issue with current development process?
1. Cherry-pick is needed for RM to choose stable fix commit after code
freeze to enforce quality.
2. Bug fix to current release branch need to be checked in both release
branch and MASTER.
3. I believe there would be more. Please comment.

B. What's the purposed process.

The idea of gitflow is from
http://nvie.com/posts/a-successful-git-branching-model/

To my understanding, compare to our current process, it suggested:
1. Develop branched out from MASTER branch, which would be what's majority
of work happens on.

   - Develop branch can merge feature branch.
   - MASTER would always be stable.

2. Feature freeze: Create Release branch: When ready to release, branch out
Release branch from Develop branch.

   - Release bug fixes only happen on Release branch.
   - Develop branch need to constantly merge Release branch for latest bug
   fixes.
   - In the meanwhile, Develop branch can still merge feature branch.

3. Code freeze: No such concept in the flow. Need to know how to guide the
check in.

4. Release. Release branch merge into MASTER. Tagged and release.

5. The original post didn't mention minor release. I suppose it may work
like this:

   1. Branch out MASTER to 4.4 release
   2. Any bug fixes happened on 4.4 need to be merge to MASTER.
   3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's needed
   is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can we fix
   it in develop branch(which meant for test)? I can't see how you can avoid
   cherry-pick or extra commit if you want to have a maintenance release.

Before realizing the maintenance release issue, I was quite like this
approach, which means no more duplicate work need to be done. But sadly the
most usage for cherry-pick is due to we need to fix multiple versions.
Current I can't see how utilize gitflow or git merge would solve the issue.
Is there a better way to handle this?

And, I think gitflow model doesn't have "code freeze" period which we can
have a gatekeeper to keep the quality. So, if we want to compare to gitflow
model, we would simply skip "code freeze" stage in our current process. I
don't think it make much sense.

I think all gitflow has is eliminate one time check in for fixing current
release branch(we need to check in both release branch and master branch)
compare to our current process, but:
1. How would it handle maintenance release?
2. How would code freeze work?
3. How about the workload for merge between release and develop branch? It
would be quite frequently.

As a developer, I hate multiple branches check in as much as anyone else,
probably even more. But I am not sure gitflow can help us here.

Btw, that no-cherry-picking(
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html) article
has a mistake in it. The result it's showing in fact shows that git cherry
-v DID recongize the cherry-pickup result by showing "-" in front of the
commit. I guess git is smart enough to know that.

Here is the manual of git-cherry.

SYNOPSIS
       git cherry [-v] [<upstream> [<head> [<limit>]]]

DESCRIPTION
       Determine whether there are commits in <head>..<upstream> that are
equivalent to those in the range <limit>..<head>.

       The equivalence test is based on the diff, after removing whitespace
and line numbers. git-cherry therefore detects when commits have been
"copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1).

       Outputs the SHA1 of every commit in <limit>..<head>, prefixed with -
for commits that have an equivalent in <upstream>, and + for commits that
do not.

--Sheng

On Tue, Jul 29, 2014 at 12:52 AM, Leo Simons <LS...@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
>
>

Re: [DISCUSS] git commit proces

[Leo Simons <LS...@schubergphilis.com>]

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

Re: [DISCUSS] git commit proces

[Daan Hoogland <da...@gmail.com>]

On Tue, Jul 29, 2014 at 1:42 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
> 'pain in the #$%#$%' and revert commits to master that don't follow the new process.
You bet I am/will be

> I expect that it will take a big of time
pun not intended, i suppose



-- 
Daan

Re: [DISCUSS] git commit proces

[Sebastien Goasguen <ru...@gmail.com>]

On Jul 29, 2014, at 4:01 AM, Daan Hoogland <da...@gmail.com> wrote:

> On Tue, Jul 29, 2014 at 5:45 AM, Sheng Yang <sh...@yasker.org> wrote:
>> I found the discussion mostly took place later
>> last week.
> 
> 
> Yes, but it was started by Rajani at May 30th (and I think it was
> mentioned even earlier) It is about time to take steps as we are at
> 4.5 freeze time.

Daan, as mentioned by Hugo, maybe you and Leo can update the Git page according to what we discussed on the long thread.

Then we need to open a VOTE thread and reach out to everyone to make sure they are aware.

If the VOTE passes, then some of us will have to become the 'pain in the #$%#$%' and revert commits to master that don't follow the new process.
I expect that it will take a big of time for everyone to adjust.

-sebastien


> 
> -- 
> Daan

Re: [DISCUSS] git commit proces

[Daan Hoogland <da...@gmail.com>]

On Tue, Jul 29, 2014 at 5:45 AM, Sheng Yang <sh...@yasker.org> wrote:
> I found the discussion mostly took place later
> last week.


Yes, but it was started by Rajani at May 30th (and I think it was
mentioned even earlier) It is about time to take steps as we are at
4.5 freeze time.

-- 
Daan

Re: [DISCUSS] git commit proces

[Sheng Yang <sh...@yasker.org>]

Sorry guys, I haven't followed up the thread. But I think we probably jump
to conclusion too quickly. I found the discussion mostly took place later
last week. I'm afraid not enough people aware of what's happening.

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?
2. What's the purposed new approach to the process?
3. What's the pro/con of the new process? And what's the pro/con of the old
one?

That would make the question much more clear.

Thanks.

--Sheng

On Mon, Jul 28, 2014 at 1:54 PM, Daan Hoogland <da...@gmail.com>
wrote:

> Rohit,
>
> Let's change the howto-use-git page after the vote.
>
> On Mon, Jul 28, 2014 at 6:47 PM, Stephen Turner
> <St...@citrix.com> wrote:
> > I am +1 on the principle.
> >
> > --
> > Stephen Turner
> >
> >
> > -----Original Message-----
> > From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> > Sent: 28 July 2014 16:08
> > To: dev
> > Subject: Re: [DISCUSS] git commit proces
> >
> > Let me explain a little more about this lat mail of mine.
> > I was assuming a lot of context that most people may not have.
> > We want to start working differently with respect to our release
> procedure and branching habits. The proposals that are out there and about
> to be voted for are going to require a lot of work of a few people and a
> lot of discipline from all of us.
> >
> > My idea was to first vote for some of the habits that are part of the
> gitflow discipline, but I am not strong opinionated about that.
> >
> > I do want to prevent that we go for a grand proposal to completely
> change our way of moving forward (not just the way we move forward) while
> there are potentially people opposing to this way of working.
> >
> > So please give a +1/0/-1 to the general idea now, so we fell comfortable
> spending the time in devising a new release schedule/mechanism.
> >
> > some of the highlights are:
> >
> > it will start with 4.5 (4.4.x will be done with the old manual
> cherry-pick process) it will require everybody to create a branch for every
> fix or feature they will contribute.
> > it will require devs to work mainly on a new branch call 'develop'
> > it will be every bodies responsibility to ensure that 'master' is at all
> times releasable
> >
> > thanks,
> > Daan
> >
> > On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> >> I am not for a grand proposal but ok, I can live with it.
> >>
> >> It would be easiest to just vote for using the gitflow model.
> >> Leo is preparing a page on how to do it. I don't know what the status
> >> is on it. The vote for my part would be on the contents of that page.
> >>
> >> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
> >> <mi...@solidfire.com> wrote:
> >>> Yeah, I was under the impression this decision would require a vote
> >>> and formal announcement, if it passes.
> >>>
> >>> On Monday, July 28, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
> >>>
> >>>> Agreed,  this kind of important decisions should be made by a vote.
> >>>>
> >>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably
> >>>> with a condensed summary of the thread?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Hugo
> >>>>
> >>>>
> >>>> On 28 jul. 2014, at 14:07, Ian Duffy <ian@ianduffy.ie
> >>>> <javascript:;>>
> >>>> wrote:
> >>>>
> >>>> > +1 to what Erik said.
> >>>> >
> >>>> >
> >>>> > On 28 July 2014 13:04, Erik Weber <terbolous@gmail.com
> >>>> > <javascript:;>>
> >>>> wrote:
> >>>> >
> >>>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland
> >>>> >> <daan.hoogland@gmail.com
> >>>> <javascript:;>>
> >>>> >> wrote:
> >>>> >>
> >>>> >>> H,
> >>>> >>>
> >>>> >>> I see a lot of commits happening directly on the master branch.
> >>>> >>> Yet there were no counter arguments against the proposed gitflow
> >>>> >>> and the discussion around it. This leaves me with the idea that
> >>>> >>> the thread is largely ignored by the community. It is my
> >>>> >>> understanding that we agreed never to commit anything to master
> >>>> >>> anymore that hasn't been first committed to a branch and is
> >>>> >>> merged back to master (instead of cherry-picked). What mistake in
> thinking am I making here?
> >>>> >>>
> >>>> >>>
> >>>> >>
> >>>> >> Not familiar with bylaws and the such, but wouldn't a change like
> >>>> >> this require some sort of voting and potentially a more formal
> information?
> >>>> >>
> >>>> >> Requiring everyone to read through a 50+ replies mail thread and
> >>>> comprehend
> >>>> >> it could be a bit much.
> >>>> >>
> >>>> >> I would suggest an updated document that explain the expected
> workflow.
> >>>> >>
> >>>> >> --
> >>>> >> Erik
> >>>> >>
> >>>>
> >>>>
> >>>
> >>> --
> >>> *Mike Tutkowski*
> >>> *Senior CloudStack Developer, SolidFire Inc.*
> >>> e: mike.tutkowski@solidfire.com
> >>> o: 303.746.7302
> >>> Advancing the way the world uses the cloud
> >>> <http://solidfire.com/solution/overview/?video=play>*™*
> >>
> >>
> >>
> >> --
> >> Daan
> >
> >
> >
> > --
> > Daan
>
>
>
> --
> Daan
>

Re: [DISCUSS] git commit proces

[Daan Hoogland <da...@gmail.com>]

Rohit,

Let's change the howto-use-git page after the vote.

On Mon, Jul 28, 2014 at 6:47 PM, Stephen Turner
<St...@citrix.com> wrote:
> I am +1 on the principle.
>
> --
> Stephen Turner
>
>
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogland@gmail.com]
> Sent: 28 July 2014 16:08
> To: dev
> Subject: Re: [DISCUSS] git commit proces
>
> Let me explain a little more about this lat mail of mine.
> I was assuming a lot of context that most people may not have.
> We want to start working differently with respect to our release procedure and branching habits. The proposals that are out there and about to be voted for are going to require a lot of work of a few people and a lot of discipline from all of us.
>
> My idea was to first vote for some of the habits that are part of the gitflow discipline, but I am not strong opinionated about that.
>
> I do want to prevent that we go for a grand proposal to completely change our way of moving forward (not just the way we move forward) while there are potentially people opposing to this way of working.
>
> So please give a +1/0/-1 to the general idea now, so we fell comfortable spending the time in devising a new release schedule/mechanism.
>
> some of the highlights are:
>
> it will start with 4.5 (4.4.x will be done with the old manual cherry-pick process) it will require everybody to create a branch for every fix or feature they will contribute.
> it will require devs to work mainly on a new branch call 'develop'
> it will be every bodies responsibility to ensure that 'master' is at all times releasable
>
> thanks,
> Daan
>
> On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland <da...@gmail.com> wrote:
>> I am not for a grand proposal but ok, I can live with it.
>>
>> It would be easiest to just vote for using the gitflow model.
>> Leo is preparing a page on how to do it. I don't know what the status
>> is on it. The vote for my part would be on the contents of that page.
>>
>> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
>> <mi...@solidfire.com> wrote:
>>> Yeah, I was under the impression this decision would require a vote
>>> and formal announcement, if it passes.
>>>
>>> On Monday, July 28, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
>>>
>>>> Agreed,  this kind of important decisions should be made by a vote.
>>>>
>>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably
>>>> with a condensed summary of the thread?
>>>>
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>>
>>>> On 28 jul. 2014, at 14:07, Ian Duffy <ian@ianduffy.ie
>>>> <javascript:;>>
>>>> wrote:
>>>>
>>>> > +1 to what Erik said.
>>>> >
>>>> >
>>>> > On 28 July 2014 13:04, Erik Weber <terbolous@gmail.com
>>>> > <javascript:;>>
>>>> wrote:
>>>> >
>>>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland
>>>> >> <daan.hoogland@gmail.com
>>>> <javascript:;>>
>>>> >> wrote:
>>>> >>
>>>> >>> H,
>>>> >>>
>>>> >>> I see a lot of commits happening directly on the master branch.
>>>> >>> Yet there were no counter arguments against the proposed gitflow
>>>> >>> and the discussion around it. This leaves me with the idea that
>>>> >>> the thread is largely ignored by the community. It is my
>>>> >>> understanding that we agreed never to commit anything to master
>>>> >>> anymore that hasn't been first committed to a branch and is
>>>> >>> merged back to master (instead of cherry-picked). What mistake in thinking am I making here?
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> Not familiar with bylaws and the such, but wouldn't a change like
>>>> >> this require some sort of voting and potentially a more formal information?
>>>> >>
>>>> >> Requiring everyone to read through a 50+ replies mail thread and
>>>> comprehend
>>>> >> it could be a bit much.
>>>> >>
>>>> >> I would suggest an updated document that explain the expected workflow.
>>>> >>
>>>> >> --
>>>> >> Erik
>>>> >>
>>>>
>>>>
>>>
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

RE: [DISCUSS] git commit proces

[Stephen Turner <St...@citrix.com>]

I am +1 on the principle.

-- 
Stephen Turner


-----Original Message-----
From: Daan Hoogland [mailto:daan.hoogland@gmail.com] 
Sent: 28 July 2014 16:08
To: dev
Subject: Re: [DISCUSS] git commit proces

Let me explain a little more about this lat mail of mine.
I was assuming a lot of context that most people may not have.
We want to start working differently with respect to our release procedure and branching habits. The proposals that are out there and about to be voted for are going to require a lot of work of a few people and a lot of discipline from all of us.

My idea was to first vote for some of the habits that are part of the gitflow discipline, but I am not strong opinionated about that.

I do want to prevent that we go for a grand proposal to completely change our way of moving forward (not just the way we move forward) while there are potentially people opposing to this way of working.

So please give a +1/0/-1 to the general idea now, so we fell comfortable spending the time in devising a new release schedule/mechanism.

some of the highlights are:

it will start with 4.5 (4.4.x will be done with the old manual cherry-pick process) it will require everybody to create a branch for every fix or feature they will contribute.
it will require devs to work mainly on a new branch call 'develop'
it will be every bodies responsibility to ensure that 'master' is at all times releasable

thanks,
Daan

On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland <da...@gmail.com> wrote:
> I am not for a grand proposal but ok, I can live with it.
>
> It would be easiest to just vote for using the gitflow model.
> Leo is preparing a page on how to do it. I don't know what the status 
> is on it. The vote for my part would be on the contents of that page.
>
> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski 
> <mi...@solidfire.com> wrote:
>> Yeah, I was under the impression this decision would require a vote 
>> and formal announcement, if it passes.
>>
>> On Monday, July 28, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
>>
>>> Agreed,  this kind of important decisions should be made by a vote.
>>>
>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably 
>>> with a condensed summary of the thread?
>>>
>>> Cheers,
>>>
>>> Hugo
>>>
>>>
>>> On 28 jul. 2014, at 14:07, Ian Duffy <ian@ianduffy.ie 
>>> <javascript:;>>
>>> wrote:
>>>
>>> > +1 to what Erik said.
>>> >
>>> >
>>> > On 28 July 2014 13:04, Erik Weber <terbolous@gmail.com 
>>> > <javascript:;>>
>>> wrote:
>>> >
>>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland 
>>> >> <daan.hoogland@gmail.com
>>> <javascript:;>>
>>> >> wrote:
>>> >>
>>> >>> H,
>>> >>>
>>> >>> I see a lot of commits happening directly on the master branch. 
>>> >>> Yet there were no counter arguments against the proposed gitflow 
>>> >>> and the discussion around it. This leaves me with the idea that 
>>> >>> the thread is largely ignored by the community. It is my 
>>> >>> understanding that we agreed never to commit anything to master 
>>> >>> anymore that hasn't been first committed to a branch and is 
>>> >>> merged back to master (instead of cherry-picked). What mistake in thinking am I making here?
>>> >>>
>>> >>>
>>> >>
>>> >> Not familiar with bylaws and the such, but wouldn't a change like 
>>> >> this require some sort of voting and potentially a more formal information?
>>> >>
>>> >> Requiring everyone to read through a 50+ replies mail thread and
>>> comprehend
>>> >> it could be a bit much.
>>> >>
>>> >> I would suggest an updated document that explain the expected workflow.
>>> >>
>>> >> --
>>> >> Erik
>>> >>
>>>
>>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>
>
>
> --
> Daan



--
Daan

Re: [DISCUSS] git commit proces

[Rohit Yadav <ro...@shapeblue.com>]

Hi,

This thread summarizes gitflow and the git process talk Rajani shared
with us in the other thread:

     http://markmail.org/message/4hk2jwvxt4lcpqig

This is what Rajani shared during the end of the thread:

     http://markmail.org/message/2642ilfajkpshnfn

After reading 58 emails on the original thread, here what I've to
suggest and discuss:

- adapt the "gitflow" to our workflow, we don't need to enforce it or
its esoteric concepts
- have a stable master because everyone ends up using master including
the new contributors

Feature development and bug fixes:
- work on a branch checked out from master or release branches
- don't commit on master by default, only if you're sure and have passed
by success builds and tests

Backporting changes: (from one branch to other branch/release)
- don't cherry pick if there are too many commits (say 50+) instead I
recommend using branching & merging
- in case of feature work/refactoring and work that results in a lot of
conflict, use squash merging that results in few revert-able commits

Open ended questions:
- How do we have a workflow that supports backporting changes/features
to old releases say 4.0, 4.1 etc.
- How do we insure this is well communicated to everyone and everyone
follows what we'll agree by vote or scout's honor
- For merging any feature work or branch or cherry-picking commits to
master do we need to have a review requirement using reviewboard etc?

Regards.

Daan Hoogland wrote:
> Let me explain a little more about this lat mail of mine.
> I was assuming a lot of context that most people may not have.
> We want to start working differently with respect to our release
> procedure and branching habits. The proposals that are out there and
> about to be voted for are going to require a lot of work of a few
> people and a lot of discipline from all of us.
>
> My idea was to first vote for some of the habits that are part of the
> gitflow discipline, but I am not strong opinionated about that.
>
> I do want to prevent that we go for a grand proposal to completely
> change our way of moving forward (not just the way we move forward)
> while there are potentially people opposing to this way of working.
>
> So please give a +1/0/-1 to the general idea now, so we fell
> comfortable spending the time in devising a new release
> schedule/mechanism.
>
> some of the highlights are:
>
> it will start with 4.5 (4.4.x will be done with the old manual
> cherry-pick process)
> it will require everybody to create a branch for every fix or feature
> they will contribute.
> it will require devs to work mainly on a new branch call 'develop'
> it will be every bodies responsibility to ensure that 'master' is at
> all times releasable
>
> thanks,
> Daan
>
> On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland<da...@gmail.com>  wrote:
>> I am not for a grand proposal but ok, I can live with it.
>>
>> It would be easiest to just vote for using the gitflow model.
>> Leo is preparing a page on how to do it. I don't know what the status
>> is on it. The vote for my part would be on the contents of that page.
>>
>> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
>> <mi...@solidfire.com>  wrote:
>>> Yeah, I was under the impression this decision would require a vote and
>>> formal announcement, if it passes.
>>>
>>> On Monday, July 28, 2014, Hugo Trippaers<hu...@trippaers.nl>  wrote:
>>>
>>>> Agreed,  this kind of important decisions should be made by a vote.
>>>>
>>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
>>>> condensed summary of the thread?
>>>>
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>>
>>>> On 28 jul. 2014, at 14:07, Ian Duffy<ian@ianduffy.ie<javascript:;>>
>>>> wrote:
>>>>
>>>>> +1 to what Erik said.
>>>>>
>>>>>
>>>>> On 28 July 2014 13:04, Erik Weber<terbolous@gmail.com<javascript:;>>
>>>> wrote:
>>>>>> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland<daan.hoogland@gmail.com
>>>> <javascript:;>>
>>>>>> wrote:
>>>>>>
>>>>>>> H,
>>>>>>>
>>>>>>> I see a lot of commits happening directly on the master branch. Yet
>>>>>>> there were no counter arguments against the proposed gitflow and the
>>>>>>> discussion around it. This leaves me with the idea that the thread is
>>>>>>> largely ignored by the community. It is my understanding that we
>>>>>>> agreed never to commit anything to master anymore that hasn't been
>>>>>>> first committed to a branch and is merged back to master (instead of
>>>>>>> cherry-picked). What mistake in thinking am I making here?
>>>>>>>
>>>>>>>
>>>>>> Not familiar with bylaws and the such, but wouldn't a change like this
>>>>>> require some sort of voting and potentially a more formal information?
>>>>>>
>>>>>> Requiring everyone to read through a 50+ replies mail thread and
>>>> comprehend
>>>>>> it could be a bit much.
>>>>>>
>>>>>> I would suggest an updated document that explain the expected workflow.
>>>>>>
>>>>>> --
>>>>>> Erik
>>>>>>
>>>>
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>>
>> --
>> Daan
>
>
>

--
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab


Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS] git commit proces

[Daan Hoogland <da...@gmail.com>]

Let me explain a little more about this lat mail of mine.
I was assuming a lot of context that most people may not have.
We want to start working differently with respect to our release
procedure and branching habits. The proposals that are out there and
about to be voted for are going to require a lot of work of a few
people and a lot of discipline from all of us.

My idea was to first vote for some of the habits that are part of the
gitflow discipline, but I am not strong opinionated about that.

I do want to prevent that we go for a grand proposal to completely
change our way of moving forward (not just the way we move forward)
while there are potentially people opposing to this way of working.

So please give a +1/0/-1 to the general idea now, so we fell
comfortable spending the time in devising a new release
schedule/mechanism.

some of the highlights are:

it will start with 4.5 (4.4.x will be done with the old manual
cherry-pick process)
it will require everybody to create a branch for every fix or feature
they will contribute.
it will require devs to work mainly on a new branch call 'develop'
it will be every bodies responsibility to ensure that 'master' is at
all times releasable

thanks,
Daan

On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland <da...@gmail.com> wrote:
> I am not for a grand proposal but ok, I can live with it.
>
> It would be easiest to just vote for using the gitflow model.
> Leo is preparing a page on how to do it. I don't know what the status
> is on it. The vote for my part would be on the contents of that page.
>
> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
> <mi...@solidfire.com> wrote:
>> Yeah, I was under the impression this decision would require a vote and
>> formal announcement, if it passes.
>>
>> On Monday, July 28, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
>>
>>> Agreed,  this kind of important decisions should be made by a vote.
>>>
>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
>>> condensed summary of the thread?
>>>
>>> Cheers,
>>>
>>> Hugo
>>>
>>>
>>> On 28 jul. 2014, at 14:07, Ian Duffy <ian@ianduffy.ie <javascript:;>>
>>> wrote:
>>>
>>> > +1 to what Erik said.
>>> >
>>> >
>>> > On 28 July 2014 13:04, Erik Weber <terbolous@gmail.com <javascript:;>>
>>> wrote:
>>> >
>>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <daan.hoogland@gmail.com
>>> <javascript:;>>
>>> >> wrote:
>>> >>
>>> >>> H,
>>> >>>
>>> >>> I see a lot of commits happening directly on the master branch. Yet
>>> >>> there were no counter arguments against the proposed gitflow and the
>>> >>> discussion around it. This leaves me with the idea that the thread is
>>> >>> largely ignored by the community. It is my understanding that we
>>> >>> agreed never to commit anything to master anymore that hasn't been
>>> >>> first committed to a branch and is merged back to master (instead of
>>> >>> cherry-picked). What mistake in thinking am I making here?
>>> >>>
>>> >>>
>>> >>
>>> >> Not familiar with bylaws and the such, but wouldn't a change like this
>>> >> require some sort of voting and potentially a more formal information?
>>> >>
>>> >> Requiring everyone to read through a 50+ replies mail thread and
>>> comprehend
>>> >> it could be a bit much.
>>> >>
>>> >> I would suggest an updated document that explain the expected workflow.
>>> >>
>>> >> --
>>> >> Erik
>>> >>
>>>
>>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>
>
>
> --
> Daan



-- 
Daan

Re: [DISCUSS] git commit proces

[Daan Hoogland <da...@gmail.com>]

I am not for a grand proposal but ok, I can live with it.

It would be easiest to just vote for using the gitflow model.
Leo is preparing a page on how to do it. I don't know what the status
is on it. The vote for my part would be on the contents of that page.

On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> Yeah, I was under the impression this decision would require a vote and
> formal announcement, if it passes.
>
> On Monday, July 28, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:
>
>> Agreed,  this kind of important decisions should be made by a vote.
>>
>> Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
>> condensed summary of the thread?
>>
>> Cheers,
>>
>> Hugo
>>
>>
>> On 28 jul. 2014, at 14:07, Ian Duffy <ian@ianduffy.ie <javascript:;>>
>> wrote:
>>
>> > +1 to what Erik said.
>> >
>> >
>> > On 28 July 2014 13:04, Erik Weber <terbolous@gmail.com <javascript:;>>
>> wrote:
>> >
>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <daan.hoogland@gmail.com
>> <javascript:;>>
>> >> wrote:
>> >>
>> >>> H,
>> >>>
>> >>> I see a lot of commits happening directly on the master branch. Yet
>> >>> there were no counter arguments against the proposed gitflow and the
>> >>> discussion around it. This leaves me with the idea that the thread is
>> >>> largely ignored by the community. It is my understanding that we
>> >>> agreed never to commit anything to master anymore that hasn't been
>> >>> first committed to a branch and is merged back to master (instead of
>> >>> cherry-picked). What mistake in thinking am I making here?
>> >>>
>> >>>
>> >>
>> >> Not familiar with bylaws and the such, but wouldn't a change like this
>> >> require some sort of voting and potentially a more formal information?
>> >>
>> >> Requiring everyone to read through a 50+ replies mail thread and
>> comprehend
>> >> it could be a bit much.
>> >>
>> >> I would suggest an updated document that explain the expected workflow.
>> >>
>> >> --
>> >> Erik
>> >>
>>
>>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*



-- 
Daan

Re: [DISCUSS] git commit proces

[Mike Tutkowski <mi...@solidfire.com>]

Yeah, I was under the impression this decision would require a vote and
formal announcement, if it passes.

On Monday, July 28, 2014, Hugo Trippaers <hu...@trippaers.nl> wrote:

> Agreed,  this kind of important decisions should be made by a vote.
>
> Sebastien, Daan, can one of you kick of the vote thread? Preferably with a
> condensed summary of the thread?
>
> Cheers,
>
> Hugo
>
>
> On 28 jul. 2014, at 14:07, Ian Duffy <ian@ianduffy.ie <javascript:;>>
> wrote:
>
> > +1 to what Erik said.
> >
> >
> > On 28 July 2014 13:04, Erik Weber <terbolous@gmail.com <javascript:;>>
> wrote:
> >
> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <daan.hoogland@gmail.com
> <javascript:;>>
> >> wrote:
> >>
> >>> H,
> >>>
> >>> I see a lot of commits happening directly on the master branch. Yet
> >>> there were no counter arguments against the proposed gitflow and the
> >>> discussion around it. This leaves me with the idea that the thread is
> >>> largely ignored by the community. It is my understanding that we
> >>> agreed never to commit anything to master anymore that hasn't been
> >>> first committed to a branch and is merged back to master (instead of
> >>> cherry-picked). What mistake in thinking am I making here?
> >>>
> >>>
> >>
> >> Not familiar with bylaws and the such, but wouldn't a change like this
> >> require some sort of voting and potentially a more formal information?
> >>
> >> Requiring everyone to read through a 50+ replies mail thread and
> comprehend
> >> it could be a bit much.
> >>
> >> I would suggest an updated document that explain the expected workflow.
> >>
> >> --
> >> Erik
> >>
>
>

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Re: [DISCUSS] git commit proces

[Hugo Trippaers <hu...@trippaers.nl>]

Agreed,  this kind of important decisions should be made by a vote.

Sebastien, Daan, can one of you kick of the vote thread? Preferably with a condensed summary of the thread?

Cheers,

Hugo


On 28 jul. 2014, at 14:07, Ian Duffy <ia...@ianduffy.ie> wrote:

> +1 to what Erik said.
> 
> 
> On 28 July 2014 13:04, Erik Weber <te...@gmail.com> wrote:
> 
>> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>> 
>>> H,
>>> 
>>> I see a lot of commits happening directly on the master branch. Yet
>>> there were no counter arguments against the proposed gitflow and the
>>> discussion around it. This leaves me with the idea that the thread is
>>> largely ignored by the community. It is my understanding that we
>>> agreed never to commit anything to master anymore that hasn't been
>>> first committed to a branch and is merged back to master (instead of
>>> cherry-picked). What mistake in thinking am I making here?
>>> 
>>> 
>> 
>> Not familiar with bylaws and the such, but wouldn't a change like this
>> require some sort of voting and potentially a more formal information?
>> 
>> Requiring everyone to read through a 50+ replies mail thread and comprehend
>> it could be a bit much.
>> 
>> I would suggest an updated document that explain the expected workflow.
>> 
>> --
>> Erik
>> 

Re: [DISCUSS] git commit proces

[Ian Duffy <ia...@ianduffy.ie>]

+1 to what Erik said.


On 28 July 2014 13:04, Erik Weber <te...@gmail.com> wrote:

> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > H,
> >
> > I see a lot of commits happening directly on the master branch. Yet
> > there were no counter arguments against the proposed gitflow and the
> > discussion around it. This leaves me with the idea that the thread is
> > largely ignored by the community. It is my understanding that we
> > agreed never to commit anything to master anymore that hasn't been
> > first committed to a branch and is merged back to master (instead of
> > cherry-picked). What mistake in thinking am I making here?
> >
> >
>
> Not familiar with bylaws and the such, but wouldn't a change like this
> require some sort of voting and potentially a more formal information?
>
> Requiring everyone to read through a 50+ replies mail thread and comprehend
> it could be a bit much.
>
> I would suggest an updated document that explain the expected workflow.
>
> --
> Erik
>

Re: [DISCUSS] git commit proces

[Erik Weber <te...@gmail.com>]

On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland <da...@gmail.com>
wrote:

> H,
>
> I see a lot of commits happening directly on the master branch. Yet
> there were no counter arguments against the proposed gitflow and the
> discussion around it. This leaves me with the idea that the thread is
> largely ignored by the community. It is my understanding that we
> agreed never to commit anything to master anymore that hasn't been
> first committed to a branch and is merged back to master (instead of
> cherry-picked). What mistake in thinking am I making here?
>
>

Not familiar with bylaws and the such, but wouldn't a change like this
require some sort of voting and potentially a more formal information?

Requiring everyone to read through a 50+ replies mail thread and comprehend
it could be a bit much.

I would suggest an updated document that explain the expected workflow.

-- 
Erik