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, 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 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. >-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. This new way would just take off the load from RM by eliminating endless cherry-picking. >
