cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanteswararao Talluri <>
Subject Re: [PROPOSAL] Move to github PR only during moratorium on commit
Date Thu, 30 Oct 2014 10:21:56 GMT
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?


On 23/10/14 11:47 am, "Animesh Chaturvedi" <>

>> -----Original Message-----
>> From: sebgoa []
>> Sent: Saturday, October 18, 2014 2:00 AM
>> To:
>> 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
>> 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
>> organization and our experience overt the last year proves my point
>> (delayed release date, broken builds, features merged without
>> We can avoid this by cutting a release branch from a stable one (from
>> 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
>> 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.
>> 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
>> 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
>> [1]
>> -sebastien

View raw message