Also with out staging, features developed by non-commiters else where, even with good code review in place there is always possibility of regression after feature merge into master.
On 07/03/13 10:41 AM, "Murali Reddy" <murali.re...@citrix.com> wrote: >On 06/03/13 11:52 PM, "Kelven Yang" <kelven.y...@citrix.com> wrote: > >>First +1 on BVT. >> >>Second, should we consider the idea of having a staging area for people >>to >>check-in? Which is that making master always the stable(reasonable) >>branch >>for main development, but whenever people make check-ins, it goes into >>staging first, > >+1 for having staging-branch. Unless we are able to run, Bvt's on the >feature branch, there is no confidence that merge of feature branch to >master won't break master. IMO, its not un-common to have a master branch >which is kept stable with regular builds and BVT test passes, then have a >development branch where the features land up first go through the BVT >then pushed to master. On regular basic there can be 'reverse integration' >(dev branch to master) and 'forward integrations' (master to dev) >automated. > >>and we have maintainers(could be automatic) to run whatever >>test framework we have and only perform automatic merge to master from >>staging area after a successful test-run? > >
