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 -a clean way to merge features and bug fixes -a clean way to create a release that should reduce our time to release
