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