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.prokharc...@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" <run...@gmail.com> wrote: > > > > >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk > ><alena.prokharc...@citrix.com> wrote: > > > >> > >> > >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <run...@gmail.com> wrote: > >> > >>> > >>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote: > >>> > >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <run...@gmail.com> > >>>> wrote: > >>>>> > >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote: > >>>>> > >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk > >>>>>> <alena.prokharc...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
