Hey Folks, After all these discussions, What is the direction to commit the code to master and 4.5? I have some commits on 4.5 which I would like to have them on master too. How to go about it?
Thanks, ~Talluri On 23/10/14 11:47 am, "Animesh Chaturvedi" <animesh.chaturv...@citrix.com> wrote: > > >> -----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
