cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanteswararao Talluri <srikanteswararao.tall...@citrix.com>
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?

Thanks,
~Talluri

On 23/10/14 11:47 am, "Animesh Chaturvedi" <animesh.chaturvedi@citrix.com>
wrote:

>
>
>> -----Original Message-----
>> From: sebgoa [mailto:runseb@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


Mime
View raw message