Here is where we stand: 1-We have a successful VOTE that got derailed after the voting period ended with a few -1 -> Since we should have a strong consensus on this that means that the VOTE is canned and folks who want a change are send back to the drawing board.
2-The main concerns I can see from the -1 are: -> No quality control in place so any change in git workflow will not help. -> Gitflow is for rolling releases and hence no suitable for cloudstack. Any other concerns ? 3-I would love for us to agree on what is wrong with our current model ? Can folks start sharing their (bullet list) thoughts. -> Master is not stable -> Too many cherry picks. Once we agree on what's wrong and what are the main concerns with the proposed git workflow, we can start drafting a plan to correct it ? -Sebastien On 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 ? >
