+1 and small changes should go through even if bigger goals glare on the horizon.
On Mon, Oct 20, 2014 at 2:14 PM, sebgoa <run...@gmail.com> wrote: > > 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 > > -- Daan
