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: [VOTE] git workflow
Date Thu, 07 Aug 2014 21:52:14 GMT
This is what I was wondering about, as well. It seems all of our 'master'
problems become 'develop' problems.

I do like the idea of merging versus cherry picking (as a general rule),
though.


On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Sebastian, addressing the following comment of yours
>
>
> "The main issue with master right now is that it moves really fast as a
> shared branch, people merge features without warning, we see regressions
> etc..
> By the time we release a major version, master has moved so much that it
> feels like starting over with the next release. It's almost as if we are
> forking our own software. CI alone (even if it were really good) will not
> fix this.”
>
>
> You will still have this problem. You cut the next release branch from the
> *develop branch, not from master. And the *develop branch will move with
> the same pace as the old master, after the release branch is cut. So
> “master moving really fast” problem would become “develop moving really
> fast”.
>
> The problems you’ve mentioned - people merge features without warning, we
> see regressions - can be fixed only with automation in place and the
> requirement to run this automation (CI/BVT) before the merge is done.
> Otherwise you are just shifting all existing problems from master to
> develop.
>
>
> -Alena.
>
>
>
> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <runseb@gmail.com> wrote:
>
> >
> >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> ><Alena.Prokharchyk@citrix.com> wrote:
> >
> >>
> >>
> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <runseb@gmail.com> wrote:
> >>
> >>>
> >>> On Aug 7, 2014, at 8:33 AM, David Nalley <david@gnsa.us> wrote:
> >>>
> >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <runseb@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <david@gnsa.us> wrote:
> >>>>>
> >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> >>>>>> <Alena.Prokharchyk@citrix.com> wrote:
> >>>>>>> Edison, thank you for raising the concern about the BVT/CI.
> >>>>>>>Somebody
> >>>>>>> mentioned earlier that we should separate git workflow
> >>>>>>> implementation from
> >>>>>>> the CI effort, but I do think we have to do in in conjunction.
> >>>>>>> Otherwise
> >>>>>>> what is the point in introducing staging/develop branch?
If there
> >>>>>>>is
> >>>>>>> no
> >>>>>>> daily automation run verifying all the code merged from
> >>>>>>> hotFixes/feature
> >>>>>>> branches (and possibly reverting wrong checkins), we can
as well
> >>>>>>> merge the
> >>>>>>> code directly to master.
> >>>>>>>
> >>>>>>
> >>>>>> Yes! - please.
> >>>>>> Doing this without CI as a gating factor buys us very little.
> >>>>>>
> >>>>>> --David
> >>>>>
> >>>>> David, can you clarify. Are you going to be against any change of
git
> >>>>> workflow until we get CI/BVT in place ?
> >>>>>
> >>>>
> >>>> No, please don't take it that way.
> >>>> I understand Leo's point about Cherry-picking being for fruit, and not
> >>>> code. But, I don't think that the workflow changes I've seen proposed
> >>>> affect quality. So shifting for quality's sake doesn't make a lot of
> >>>> sense in my mind. They could be a component of fixing the quality
> >>>> problem.
> >>>>
> >>>> --David
> >>>
> >>> Agreed, the changes don't affect quality but should support a CI infra
> >>> that helps improves quality.
> >>>
> >>> I do think the changes provide
> >>>
> >>> -a stable master that represent released software
> >>
> >>
> >> You can always look at the latest release branch to get it,
> >
> >Yes I know how to get to the latest released software.
> >
> >I actually don't have good answers for your questions but I think Nate's
> >email (couple emails back) answers a lot of them.
> >
> >> as we are
> >> planning to keep them around to support maintenance. From the developer
> >> stand point, I would be more interested in getting the latest stable
> >>code,
> >> not the latest stable release.
> >
> >I think that's fine from a developer standpoint. I tend to look at things
> >from a user standpoint.
> >I think a basic user who wants to check out source (because he builds his
> >own packages), would like to checkout the latest master to get the latest
> >released software (not everybody software projects works like this of
> >course).
> >
> >The main issue with master right now is that it moves really fast as a
> >shared branch, people merge features without warning, we see regressions
> >etc..
> >By the time we release a major version, master has moved so much that it
> >feels like starting over with the next release. It's almost as if we are
> >forking our own software. CI alone (even if it were really good) will not
> >fix this.
> >
> >So assuming we have CI in place, we do need a better workflow (let's not
> >call it gitflow anymore) to self-discipline ourselves.
> >
> >>
> >> I don¹t see the use of stable master branch during the release either,
> >>as
> >> it reflects already released versions of the CS. And you never cut the
> >> release from the stable master branch; you do cut it from *develop -
> >> that¹s what the git workflow suggests.
> >
> >That's where our use case differs from gitflow. Several folks have
> >already mentioned that we are going to deviate from pure gitflow, it is
> >just a nice framework to start creating our own workflow.
> >
> >Personally, I would love to cut the release branches from master (instead
> >of develop). that way you always start from a clean slate, instead of the
> >mess with start with right now.
> >
> >Say develop is more of a staging branch, as you have advocated. We can
> >run CI/BVT on that branch (we should run it everywhere…but anyway) and
> >make sure features merged in work as advertized.
> >
> >When time comes to release, we cut from master and merge the features
> >that have been merged in develop already, then go into QA, merge the
> >fixes back to develop etc….when released, we merge back to master.
> >
> >If/since we don't do rolling releases, we branch out from the main
> >version tag and do a maintenance release that leaves on, assuming it
> >can't get merged back into master.
> >
> >>
> >>> -a clean way to merge features and bug fixes
> >>
> >> +1
> >>
> >>> -a clean way to create a release that should reduce our time to release
> >>
> >> +1 Although I still think that slowness for our release was mostly
> >>caused
> >> by the last minute regression bugs caused by missing quality control +
> >> lack of CI.
> >
> >True, but it is also due to the fact that we start a release branch from
> >a messy master where regressions happen.
> >
> >> This new way would just take off the load from RM by
> >> eliminating endless cherry-picking.
> >>
> >
> >I would love to have a workflow where the RM has a very clean job (pick
> >the features that should be in the release, pick the hot fixes release).
> >It should just be a series of git merge and that's it.
> >
> >master branch is only released software, only touched by RMs
> >
> >released branches only touched by RMs
> >
> >develop shared but merges happen only after successful CI and guarantee
> >of no regressions.
> >
> >>
> >>>
> >>
> >
>
>


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