On Oct 20, 2014, at 1:51 PM, Stephen Turner <stephen.tur...@citrix.com> wrote:
> As I just said in the other thread -- but to repeat it here in the PROPOSAL > thread -- > > I am +1 on using github pull requests. > > I am +1 on all code changes being reviewed by a committer other than the > author, as well as undergoing some automated CI testing, before the pull > request is merged. > > I am +0 on only the master RM merging the pull request. I don't want the > author to push the code, but I think the code reviewer could do this; in > practice the RM will not be able to review everything again so is likely to > rubber-stamp the results of the code review / automated testing. But I could > live with the master RM doing it. > Understood, the idea is to go with this drastic change and as we adjust we can relax a bit this constraint. The benefit is to start controlling what will go in the next release before a release branch is even cut and get all developers (committers or not) to start using feature branches systematically. > I am +1 on moving ahead with any of these parts individually, rather than > waiting for everything to be in place before doing anything. > > -- > Stephen Turner > > > -----Original Message----- > From: sebgoa [mailto:run...@gmail.com] > Sent: 18 October 2014 10:00 > To: dev@cloudstack.apache.org > Subject: [PROPOSAL] Move to github PR only during moratorium on commit > > After [1] I would like to officially bring up the following proposal. > > [Proposal] > ---- > All commits come through github PR, *even* for committers. We declare a > moratorium period (agreed suspension of activity) during which direct commit > to master is forbidden. > Only the master RM is allowed to merge PR in master (we define a master RM). > If direct commit to master is done, master RM reverts without warning. Same > for 4.5 and 4.4. branches. > ---- > > This is drastic and I am sure some folks will not like it, but here is my > justification for such a measure: > > [Reasons]: > ---- > Our commit and release processes have so far been based on the idea that > development happens on master and that a release branch is cut from master > (unstable development branch). Then a different set of community members > harden the release branch, QA and bring it to GA level. During that time > development keeps on going in master. > > This is an OK process if we have the luxury of having a QA team and can cope > with split personality of being developers and release managers. > > My point of view is that as a community we cannot afford such a split brain > organization and our experience overt the last year proves my point (delayed > release date, broken builds, features merged without warning...) > > We can avoid this by cutting a release branch from a stable one (from the > start), then as you (Daan) have mentioned several times, fix bugs in the > release branch and merge them back in the stable source of the release (be it > master). > > Feature development need to be done outside master, period. Not only for > non-committers but also for committers. And merge request need to be called. > This will help review and avoid surprises. > > New git workflow were proposed and shutdown, mostly calling for better CI to > solve quality issues. CI will not solve our quality issues alone. We need to > better police ourselves. > > To avoid long discussions, I propose this simple but drastic measure. We move > all our commits to github PR until 4.5 is out, this stands for committers and > non-committers, direct commits (especially to master) would be reverted > immediately. > ---- > > Our development and release process is broken, we cannot continue like this, > let's fix it. > > [1] http://markmail.org/thread/xeliefp3oleq3g54 > > -sebastien
