I like the way Stephen split it. Here is my vote. +1 on using github pull requests. +1 on compulsory code reviews and PRs even for committers and CI build pass before merging. +1 on merges from 4.5 to master and no individual commits(or cherry-picks) to the branches +0 on RM for master and commits gated by him. I agree with Stephen that code reviewer should be doing the push. But, I am ok with RM doing it(assuming we have a volunteer ;) ).
+1 on any changes independently. ~Rajani On Mon, Oct 20, 2014 at 5:21 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. > > 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 >
