A git workflow change will not solve the quality problems we have. They have to be dealt with independently. Just because we are changing the way we commit the code doesnt mean we wont have any quality issues introduced by the commits. It just ensures that issues/fixes are properly transferred to the next releases and we have a better way to understand where all the issue is fixed/or first seen.
Yes the problems we have on master will shift to develop branch. But the workflow change is not intended to solve them. It cannot tell us how to write bug free code/ inform there are bugs. What is the problem with having stable master branch pointing to latest release? Any user/developer who wants to try out cloudstack, can just checkout code and deploy and gets a nice first impression. Without having to look at what is the latest release whether 4.4 is stable or 4.3.1 or 4.2. In my opinion thats a big advantage. At this point, we arent sure that if we pass BVT, then we can release the code. Though that can be the first step( See 4.4 for example.) When we reach such a point, then we can merge stuff to master as soon as they pass BVT. But, until then it has to be the released code in my opinion. Following git-flow doesnt mean we have to follow each and every aspect of it. Lets start with it and make any amendments as required to fit our way. As the git-flow says a fix from support branch should reach master through hotfix doesnt mean we have to follow the same. If you feel they havent diverged a lot and can be merged, that can be merged. The important thing being, if the bug is relevant for the next release, it should go to develop/master. Also, as leo already said earlier, cherry-picking in itself is not the devil. The tool exists for a reason and it has to be used when required. For example when you are backporting a fix from minor release(which has diverged a lot from master and doesn't make sense to merge) (The discussion[s] has been so long that I feel like I am repeating my self) we haven't planned 4.5 yet though the code freeze date is long gone. We don't have RM for it. We have to release 4.4.1 immediately(It is a hotfix). This discussion is masking everything else. As we all agree that we have to solve the cherry-picking issue we have, can we focus on that please? We can get back to staging/develop branch later. CI/BVT as and when they are available. step-by-step. Let us use our current model with minor change that no cherry-picking after the release branch is created. Lets just work on the release branch directly. 1. it should only contain bug fixes and any bug going to the branch should be discussed/notified on the dev list(preferably before you work on it). 2. It should be merged/committed to the release branch only after it passes BVT(whether you run it locally or let jenkins run it by creating a hotfix/CS-* branch). thoughts? On Fri, Aug 8, 2014 at 3:22 AM, Mike Tutkowski <mike.tutkow...@solidfire.com > wrote: > 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>*™* > -- ~Rajani
