I could get easily merge all my changes in 4.5 to master yesterday. Merge to master is no more a problem. Thanks to Rajani for fixing merge issues with master. I think, at least, from now we can keep the master mergable.
For others who are interested in knowing what I¹ve just tried: 1. <push your changes to 4.5> 2. Git checkout master 3. Git pull 4. Git merge 4.5 Thanks, ~Talluri On 30/10/14 3:51 pm, "Srikanteswararao Talluri" <srikanteswararao.tall...@citrix.com> wrote: >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 >
