cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Tue, 08 Jul 2014 16:04:12 GMT
Thanks for bringing this up again, Sebastien.

I've had http://nvie.com/posts/a-successful-git-branching-model/ up in
Chrome since you sent that link and been reading through it a bit here and
there, but have just been too busy as of late to give it a bunch of thought.

I agree, though, that we should really think about moving to another model
of using Git as it is not un-common for master to be broken, which leads to
a lot of lost development time for many people.


On Mon, Jun 30, 2014 at 4:09 PM, 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>*™*
> >>>>
> >>>
> >>>
> >
>
>


-- 
*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>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message