cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Wed, 23 Jul 2014 15:51:43 GMT

On Jul 23, 2014, at 11:38 AM, daan Hoogland <daan.hoogland@gmail.com> wrote:

> Sebastien,
> 
> It seems we can do what you are calling for is creating a branch
> called 'release'. We can merge back into that branch from 4.4, master,
> 4.3. I would like to see people that want a feature or bug fix in a
> branch make a fork of that branch and when that fork is working do a
> cherry-pick. The -forward concept is now used for that but it is
> broken because more then for one piece of work there are commits on
> it. This caused me conflicts during the release. Especially painfull
> as not all was intended to get into the release. We can create this
> 'release' branch now on the basis of 4.4 and start pulling in changes.

Yes, that's what I am thinking about too, so +1

Our master would become the -develop- in gitflow terms
The release branch you mention would become the -master- in gitflow terms

If we start now, indeed we can create 'release' from 4.4 release tag (voted and shipped).

That means that to create 4.5 we will need to merge features back into 'release'. it might
be messy because some of those features are already in our current master.

But all of this will keep 'release' clean (we can keep track of bugs and features that are
in it in CHANGES file etc..) 


> There is a question of control. Do we allow all committers to manage
> the release? I am for that but can imagine not everybody is.
> 

At first I would say that only the RM can commit to 'release'. As we get the CI in place 
we could relax this and allow commits that pass the CI to get into 'release', but right now
I would vote for a tighter control of 'release'.

> rule number 1 will be: you are going to do something to the code, you
> start by creating a branch.
> 
> right?
> 
> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <runseb@gmail.com> wrote:
>> 
>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sam.schmit@appcore.com> wrote:
>> 
>>> Hey everyone,
>>> 
>>> I've been a developer for a handful of years and have had my share of
>>> experience with different version control systems.  I've used (for better
>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
>>> 
>>> Each of these solutions offers their own unique set of features, strengths
>>> and weaknesses.  As there are so many systems that are good at specific
>>> things, it seems best to use the features that the chosen system is best at.
>>> 
>>> Git is great at branching, merging and using that structure to maintain and
>>> control how changes get into the primary branches.  Git tools even make
>>> this easy by integrating directly into the "Gitflow" to make branching and
>>> merging that much easier.  It would seem counter-intuitive to NOT make use
>>> of these built-in capabilities.
>>> 
>>> In addition to that, I know that the current method of change management is
>>> incredibly frustrating to work with, and works directly against the way a
>>> typical Git user would expect it to be structured.  I should NEVER have
>>> problem compiling and running something on master.  I should not have
>>> problems building anything on a release branch.  A feature/bugfix branch is
>>> where things can be, and often are, broken or unstable.  There have been
>>> many times working in Cloudstack where I've had to search for a stable
>>> revision on master, and that's just plain wrong.
>>> 
>>> I do realize that having this many developers working on so many features
>>> and bugfixes will result in a large number of branches.  I don't believe
>>> this is a good argument against using a branching method, though - I
>>> believe that the current system is even more confusing and difficult to use.
>>> 
>>> I could pontificate on change management quite a bit more, but my opinion
>>> in summary would basically be:  use Git the way it was meant to be used,
>>> and things will be better.  Just my two cents.
>>> 
>>> Sam
>>> 
>>> 
>> 
>> Sam, I think we are in agreement (at least with folks who responded to this thread).
>> Or maybe I am not reading your mail right and you don't agree with Leo ?
>> 
>> My own take and reason for calling for a change we are currently doing things is
mostly due to the way we release.
>> 
>> I would like to see a stable master (and I think we are in agreement with that).
>> That means that development should not happen on master and that every commit that
lands on master should be shippable.
>> 
>> I personally have no issues with cherry-picking. So I would be fine cherry picking
from a hot-fix branch into master, to fix a bug.
>> The end result is that the next commit on master would still mean master is shippable/releasable.
>> 
>> If we agree with this basic concept. The question becomes how do we get there, considering
that master is now full of dev work and potential bug.
>> The only releasable product we have are on the 4.3, 4.4 and previous release branches.
>> 
>> Ideally, I would like to see master becomes 4.4. And work our way back, merging the
new features that are already in master into the new master (based on 4.4).
>> This could be quite complicated but we need to do it (or something like it).
>> 
>> To move forward, we should make a proposal to the list and call for a vote.
>> 
>> Any takers to start a wiki page proposing a new git process and how we could move
to it (transition path) ?
>> 
>> 
>> -Sebastien
>> 
>> 
>>> 
>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <LSimons@schubergphilis.com>
>>> wrote:
>>> 
>>>> Hey folks,
>>>> 
>>>> With 4.4.0 tagged, is now an opportune time to go and implement this?
>>>> 
>>>> I would enthousiastically +1 and get crackin', but I’m not a committer
so
>>>> its not that practical for me to volunteer!
>>>> 
>>>> I wanted to point out atlassian’s description of gitflow
>>>> 
>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
>>>> 
>>>> which might be easier to read.
>>>> 
>>>> Similarly, the git-flow scripts that help out with implementing this stuff
>>>> 
>>>> https://github.com/nvie/gitflow
>>>> 
>>>> they also describe the relationship between gitflow and dealing with
>>>> multiple remotes
>>>> 
>>>> https://www.atlassian.com/git/workflows#!pull-request
>>>> 
>>>> Finally note atlassian’s free sourcetree GUI has built-in support for
>>>> git-flow
>>>> 
>>>> http://www.sourcetreeapp.com/
>>>> 
>>>> Because cloudstack currently is full of rebasing and squashing and
>>>> cherry-picking, you get very little benefit from a tree visualization tool
>>>> (like this or gitk or ...) right now, but it would be *great* to have going
>>>> forward.
>>>> 
>>>> 
>>>> cheers,
>>>> 
>>>> 
>>>> Leo
>>>> 
>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com>
wrote:
>>>> 
>>>>> I would like to re-start this discussion.
>>>>> 
>>>>> Rajani made some good points and someone mentioned Gitflow:
>>>>> 
>>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>> 
>>>>> Thinking about our release procedure, we clearly need more tests and
a
>>>> CI. However it looks like this is going to take some time.
>>>>> 
>>>>> In the meantime I think there is nothing preventing us from agreeing
to
>>>> 'git practices', we don't need tests or new infra, we just need to agree
on
>>>> the git workflow.
>>>>> 
>>>>> Right now Master is really a development branch, we should make it a
>>>> stable branch for production with very few commits.
>>>>> This does not mean that we would release less, in contrary this would
>>>> ensure that a commit to master means it's a production release.
>>>>> 
>>>>> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's
>>>> point) everything is based on merges.
>>>>> 
>>>>> I am of the opinion that git flow provides a nice process. It basically
>>>> freezes master. Development happens in a 'develop' branch, releases
>>>> branches are branched off of that and merged into master and back into
>>>> develop….etc
>>>>> 
>>>>> Please read [1] it's a good read.
>>>>> 
>>>>> And let's discuss,
>>>>> 
>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
>>>>> 
>>>>> -Sebastien
>>>>> 
>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Rajani.Karuturi@citrix.com>
>>>> wrote:
>>>>> 
>>>>>> There is also the problem of cherry-picking.
>>>>>> As a contributor, I always endup creating multiple patches for each
>>>> branch as they don’t cleanly apply on the upward branches. which means
>>>> distinct commits for each branch and I don’t easily know which all branches
>>>> my commit exists unless I do grep.
>>>>>> if we follow merging strategy properly, apart from the first merge
of
>>>> the branch, everything else on top of it should be a painless merge.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ~Rajani
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <shadowsor@gmail.com> wrote:
>>>>>> 
>>>>>>> I think many of the bullet points are what we are currently doing
>>>>>>> (guidelines for commit comments, feature branches need to stay
in sync
>>>> with
>>>>>>> master, no back-merging). I also think that much of what we do
now is
>>>> done
>>>>>>> the way it is simply because there *are* vast changes between
versions.
>>>>>>> Classes are getting shuffled around and changed all the time.
If its
>>>>>>> feasible to merge branch fixes to master, that's fine, but some
quick
>>>> tests
>>>>>>> seem to indicate that this will be messy getting started.
>>>>>>> 
>>>>>>> That leaves us with how we do releases. I'm fine with having
single
>>>>>>> branches for major releases(4.3) and tagging the commits where
each
>>>>>>> incremental release (4.3.x) is done. I'm trying to remember why
we went
>>>>>>> with the -forward, I'm sure it's in the mailing list somewhere,
but
>>>> one of
>>>>>>> the nice things it provides is the ability for the release manager
to
>>>>>>> control what changes are made during code freeze while giving
people a
>>>>>>> place to stage fixes (though admittedly this is not always followed).
>>>>>>> Without -forward, would the flow be for each dev to have their
own
>>>> repo and
>>>>>>> issue pull requests for bugfixes?
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
>>>> Rajani.Karuturi@citrix.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Any other suggestions/objections/comments??
>>>>>>>> Can we discuss this in detail and agree to a process??
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ~Rajani
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
>>>> Rajani.Karuturi@citrix.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Yes as mike said, if its a one-off case we can do a empty
>>>> merge(merge -s
>>>>>>>> ours) for it and git will assume its merged but will not
bring in any
>>>>>>>> changes.
>>>>>>>>> 
>>>>>>>>> If the branches diverged a lot, for example after a major
rewrite, we
>>>>>>>> could stop merging to that branch and above and make the
fix manually.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ~Rajani
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Yep, that's what I was referring to in that a particular
fix for an
>>>> old
>>>>>>>>>> release may not apply to newer versions. That does
happen.
>>>>>>>>>> 
>>>>>>>>>> We used to mark those as "don't need to merge to
branch x" in SVN
>>>> and
>>>>>>>> then
>>>>>>>>>> you handed it however made sense on the applicable
branch(es).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner
<
>>>>>>>> Stephen.Turner@citrix.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> What happens if a fix isn't relevant for newer
versions, or has to
>>>> be
>>>>>>>>>>> rewritten for newer versions because the code
has changed? Don't
>>>> the
>>>>>>>>>>> branches diverge and you end up cherry-picking
after that?
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Stephen Turner
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>>>>>>> Sent: 30 May 2014 18:48
>>>>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
>>>>>>>>>>> 
>>>>>>>>>>> I think this flow is something we should seriously
consider.
>>>>>>>>>>> 
>>>>>>>>>>> I find cherry picking from branch to branch to
be error prone in
>>>> that
>>>>>>>> it's
>>>>>>>>>>> easy for someone to forget to cherry pick to
all applicable
>>>> branches
>>>>>>>> and
>>>>>>>>>>> you don't have any easy way to see the cherry
picks are related.
>>>>>>>>>>> 
>>>>>>>>>>> When I worked at HP, we had automated tools check
to see if you
>>>>>>>> checked a
>>>>>>>>>>> fix into a prior release, but not later releases.
In such a
>>>> situation,
>>>>>>>> you
>>>>>>>>>>> either 1) forgot to perform the check-in or 2)
the check-in was no
>>>>>>>> longer
>>>>>>>>>>> applicable in the later release(s), so you needed
to mark it as
>>>>>>>>>>> un-necessary (SVN supported this ability...not
sure about Git).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi
<
>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Our current git workflow is confusing with
the *forward branches
>>>> and
>>>>>>>>>>>> cherry-picking. Its hard to track on what
all releases the commit
>>>> has
>>>>>>>>>>>> gone into unless I do some git log greping.
Also, as a
>>>> contributor, I
>>>>>>>>>>>> endup creating patches for each branch as
it doesn’t cleanly
>>>> apply on
>>>>>>>>>>>> different branches.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I think we should have some guidelines. Here
is what I propose.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 1.  There should be branch for every major
release(ex: 4.3.x,
>>>> 4.4.x,
>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should
be tagged accordingly
>>>> on
>>>>>>>>>>>> the respective branches.
>>>>>>>>>>>> 2.  The branch naming convention is to be
followed. Many branches
>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In
git, when we cherry-pick,
>>>>>>>>>>>> we have two physically distinct commits for
the same change or
>>>> fix and
>>>>>>>>>>>> is difficult to track unless you do cherry-pick
-x
>>>>>>>>>>>> 4.  There should always be a continous flow
from release branches
>>>> to
>>>>>>>>>>>> master. This doesn’t mean cherry-picking.
They should be
>>>> merged(either
>>>>>>>>>>>> ff or no-ff) which retains the commit ids
and easily trackable
>>>> with
>>>>>>>>>>>> git branch --contains
>>>>>>>>>>>> *   Every bug fix should always flow from
minimal release uptill
>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
master.
>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed
to
>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
>>>>>>>>>>>> *   If someone forgets to do the merge, the
next time a new commit
>>>>>>>>>>> is
>>>>>>>>>>>> done this will also get merged.
>>>>>>>>>>>> 5.  There should always be a continuous flow
from master to
>>>> feature
>>>>>>>>>>>> branches. Meaning all feature branch owners
should proactively
>>>> take
>>>>>>>>>>>> any new commits from master by doing a merge
from master
>>>>>>>>>>>> 6.  The commits from feature branch will
make to master on code
>>>>>>>>>>>> complete through a merge.
>>>>>>>>>>>> 7.  There should never be a merge from master
to release branches
>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted
to any minor release)
>>>>>>>>>>>> should have atleast bug id and correct author
information
>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
reviewed by
>>>>>>>> <committer>
>>>>>>>>>>>> for CASSANDRA-<ticket>
>>>>>>>>>>>> 9.  Once the release branch is created(after
code freeze), any bug
>>>>>>>>>>>> in jira can be marked with fix version current
release(4.4) only
>>>> on
>>>>>>>>>>>> RM's approval and only they can go to the
release branch.  This
>>>> can be
>>>>>>>>>>>> done through jira and with certain rules.(may
be using jira vote?)
>>>>>>>>>>>> this would save the cherry-picking time and
another branch
>>>>>>>> maintenance.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Ref:
>>>>>>>>>>>> 
>>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
>>>>>>>>>>>> 
>>>>>>>>>>>> ~Rajani
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> *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>*™*
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> *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


Mime
View raw message