3 it should be made in a hotfix/4.4-<jira number> branch and reviewed and merged from there
On Fri, Aug 8, 2014 at 9:16 AM, Rajani Karuturi <raj...@apache.org> wrote: > 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 -- Daan
