> -----Original Message----- > From: sebgoa [mailto:run...@gmail.com] > Sent: Saturday, October 18, 2014 2:00 AM > 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).
[Animesh] Sebastian you have brought up a good point dependency on QA team from Citrix is an issue for the project. This was raised in the past as well and Alex's proposal [1] few months back using CI was in my opinion is the optimal solution. Why? Because CloudStack is a huge project and one single person cannot have the full knowledge to safely review all the code and certainly cannot scale, which CI and automation can address Keeping master stable is something no one would argue against and my point would match the original proposal from Alex. May be we can have a staging branch for master and then merging the commit only after they have passed CI into master. The proposal got derailed and delayed because as called out at that time community does not want to work with a process that has a dependency on infrastructure that is not controlled by community. David and I are working to get the hardware from Citrix into ACS infra. The approach for fixing issues in release branch first and master later is not practical as we may miss out commits not made into master and future release regressing without the fixes. Also as the release goes into hardening cycle there will be a number of fixes which will not be allowed in release branch but need to be fixes for future, they should all go in master. Master is the catch all default branch and in my opinion should get fixes first. [1] http://markmail.org/thread/xoyjw2sduenlytwm > > 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. > [Animesh] Completely Agreed > 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. > [Animesh] I have already expressed my opinion in favor of CI > 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. [Animesh] I followed up the release process as established by Chip for 4.2 and 4.3 release for which I was the RM and frankly I did not feel it that way other than the pain of multiple RCs. Folks may not like it but I am entitled to my opinion and I do feel part of the issues for 4.4 were self- inflicted because of pre mature code freeze and too early cherry picking. > > [1] http://markmail.org/thread/xeliefp3oleq3g54 > > -sebastien
