Re: [PROPOSAL] Move to github PR only during moratorium on commit
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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
These problems existed for 4.4 and the same continued to 4.5. Despite discussing lot of things, we didnt act on anything and we are continuing the same to 4.6 There is no plan whatsoever to address any of those issues. ~Rajani On Wed, Nov 5, 2014 at 2:33 AM, David Nalley da...@gnsa.us wrote: On Sun, Nov 2, 2014 at 11:40 PM, Rajani Karuturi raj...@apache.org wrote: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. I don't think we are running away from them. I certainly hope not. There are competing demands (like everything) 1. We want to ship 4.5 2. We want to have new features being developed 3. We want to fix quality issues 4. We want to fix process issues Each of those is at odds with each other. They are also hard problems, and frankly most of them are as much a cultural problem as a technical problem. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? We are saying that #2 forced us to fork 4.5 into a different branch. Master and 4.5 are now diverging, and we want to #1 to happen. 1 2 are incompatible on the same branch, but their competition is keeping 3 and 4 at bay. That doesn't mean we shouldn't change, but you can only pull in so many directions without things coming apart. --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Travis is happy with the merge. Can I push this? ~Rajani On Wed, Nov 5, 2014 at 12:38 PM, Rajani Karuturi raj...@apache.org wrote: I did merge -s ours and somehow didnt see any issue. ( https://github.com/apache/cloudstack/pull/36) will wait for the Travis report ( https://travis-ci.org/apache/cloudstack/builds/40033174) I havent used -X before. But, from the documentation I understood it as, the merge strategy will be applied only when doing a conflict resolution. If my understanding is right, we shouldnt be using -X. ~Rajani On Mon, Nov 3, 2014 at 3:46 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help. mobile dev with bilingual spelling checker used (read at your own risk) Op 3 nov. 2014 05:40 schreef Rajani Karuturi raj...@apache.org: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? ~Rajani PS: We could still do a blank merge(-s ours) from 4.5 to master and continue. On Sat, Nov 1, 2014 at 12:06 AM, David Nalley da...@gnsa.us wrote: On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi raj...@apache.org wrote: Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. It won't work; master and 4.5 have both diverged, even if it's very small at this point. Daan and I both seemed to come to this conclusion last week: http://markmail.org/message/sumgmlo4avgjquym http://markmail.org/message/wazq4lz47v22mynz --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
as Travis is happy and some of my tests went fine, I pushed the merge. ~Rajani On Wed, Nov 5, 2014 at 2:55 PM, Rajani Karuturi raj...@apache.org wrote: Travis is happy with the merge. Can I push this? ~Rajani On Wed, Nov 5, 2014 at 12:38 PM, Rajani Karuturi raj...@apache.org wrote: I did merge -s ours and somehow didnt see any issue. ( https://github.com/apache/cloudstack/pull/36) will wait for the Travis report ( https://travis-ci.org/apache/cloudstack/builds/40033174) I havent used -X before. But, from the documentation I understood it as, the merge strategy will be applied only when doing a conflict resolution. If my understanding is right, we shouldnt be using -X. ~Rajani On Mon, Nov 3, 2014 at 3:46 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help. mobile dev with bilingual spelling checker used (read at your own risk) Op 3 nov. 2014 05:40 schreef Rajani Karuturi raj...@apache.org: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? ~Rajani PS: We could still do a blank merge(-s ours) from 4.5 to master and continue. On Sat, Nov 1, 2014 at 12:06 AM, David Nalley da...@gnsa.us wrote: On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi raj...@apache.org wrote: Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. It won't work; master and 4.5 have both diverged, even if it's very small at this point. Daan and I both seemed to come to this conclusion last week: http://markmail.org/message/sumgmlo4avgjquym http://markmail.org/message/wazq4lz47v22mynz --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
I share your frustration Rajani, I made some steps which I feel are turned back now. I am giving up and really not feeling this is worth my effort anymore. People don't take the effort to commit on a branch. gating commits is and will not solve unwillingness. It will slow us down at committing bugs and force us to make more elaborate bugs at best. merge forward is easy to implement *if we want it*. wanting is is a must have prequisite. On Wed, Nov 5, 2014 at 10:24 AM, Rajani Karuturi raj...@apache.org wrote: These problems existed for 4.4 and the same continued to 4.5. Despite discussing lot of things, we didnt act on anything and we are continuing the same to 4.6 There is no plan whatsoever to address any of those issues. ~Rajani On Wed, Nov 5, 2014 at 2:33 AM, David Nalley da...@gnsa.us wrote: On Sun, Nov 2, 2014 at 11:40 PM, Rajani Karuturi raj...@apache.org wrote: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. I don't think we are running away from them. I certainly hope not. There are competing demands (like everything) 1. We want to ship 4.5 2. We want to have new features being developed 3. We want to fix quality issues 4. We want to fix process issues Each of those is at odds with each other. They are also hard problems, and frankly most of them are as much a cultural problem as a technical problem. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? We are saying that #2 forced us to fork 4.5 into a different branch. Master and 4.5 are now diverging, and we want to #1 to happen. 1 2 are incompatible on the same branch, but their competition is keeping 3 and 4 at bay. That doesn't mean we shouldn't change, but you can only pull in so many directions without things coming apart. --David -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Sun, Nov 2, 2014 at 11:40 PM, Rajani Karuturi raj...@apache.org wrote: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. I don't think we are running away from them. I certainly hope not. There are competing demands (like everything) 1. We want to ship 4.5 2. We want to have new features being developed 3. We want to fix quality issues 4. We want to fix process issues Each of those is at odds with each other. They are also hard problems, and frankly most of them are as much a cultural problem as a technical problem. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? We are saying that #2 forced us to fork 4.5 into a different branch. Master and 4.5 are now diverging, and we want to #1 to happen. 1 2 are incompatible on the same branch, but their competition is keeping 3 and 4 at bay. That doesn't mean we shouldn't change, but you can only pull in so many directions without things coming apart. --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
I did merge -s ours and somehow didnt see any issue. ( https://github.com/apache/cloudstack/pull/36) will wait for the Travis report ( https://travis-ci.org/apache/cloudstack/builds/40033174) I havent used -X before. But, from the documentation I understood it as, the merge strategy will be applied only when doing a conflict resolution. If my understanding is right, we shouldnt be using -X. ~Rajani On Mon, Nov 3, 2014 at 3:46 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help. mobile dev with bilingual spelling checker used (read at your own risk) Op 3 nov. 2014 05:40 schreef Rajani Karuturi raj...@apache.org: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? ~Rajani PS: We could still do a blank merge(-s ours) from 4.5 to master and continue. On Sat, Nov 1, 2014 at 12:06 AM, David Nalley da...@gnsa.us wrote: On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi raj...@apache.org wrote: Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. It won't work; master and 4.5 have both diverged, even if it's very small at this point. Daan and I both seemed to come to this conclusion last week: http://markmail.org/message/sumgmlo4avgjquym http://markmail.org/message/wazq4lz47v22mynz --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Id did do -s ours:) but if we don't merge -s ... -X ours it doesn't help. mobile dev with bilingual spelling checker used (read at your own risk) Op 3 nov. 2014 05:40 schreef Rajani Karuturi raj...@apache.org: that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? ~Rajani PS: We could still do a blank merge(-s ours) from 4.5 to master and continue. On Sat, Nov 1, 2014 at 12:06 AM, David Nalley da...@gnsa.us wrote: On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi raj...@apache.org wrote: Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. It won't work; master and 4.5 have both diverged, even if it's very small at this point. Daan and I both seemed to come to this conclusion last week: http://markmail.org/message/sumgmlo4avgjquym http://markmail.org/message/wazq4lz47v22mynz --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
that means, we postponed the git problems to 4.6. :( It feels like as a community we are running away from making any changes to the way we interact with git. We seem to discuss it a lot but, never act on it. What I don't understand is, are we saying the way we use git is right? or are we just shying away from any change? ~Rajani PS: We could still do a blank merge(-s ours) from 4.5 to master and continue. On Sat, Nov 1, 2014 at 12:06 AM, David Nalley da...@gnsa.us wrote: On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi raj...@apache.org wrote: Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. It won't work; master and 4.5 have both diverged, even if it's very small at this point. Daan and I both seemed to come to this conclusion last week: http://markmail.org/message/sumgmlo4avgjquym http://markmail.org/message/wazq4lz47v22mynz --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Fri, Oct 31, 2014 at 12:41 AM, Rajani Karuturi raj...@apache.org wrote: Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. It won't work; master and 4.5 have both diverged, even if it's very small at this point. Daan and I both seemed to come to this conclusion last week: http://markmail.org/message/sumgmlo4avgjquym http://markmail.org/message/wazq4lz47v22mynz --David
Re: [PROPOSAL] Move to github PR only during moratorium on commit
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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Commit to 4.5 and master please. --David On Thu, Oct 30, 2014 at 6:21 AM, 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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Can we atleast follow the merge part of it? ie) commit to 4.5 and then merge 4.5 to master? merging wont be easy unless everybody agrees and does merge for their commits. ~Rajani On Thu, Oct 30, 2014 at 8:44 PM, David Nalley da...@gnsa.us wrote: Commit to 4.5 and master please. --David On Thu, Oct 30, 2014 at 6:21 AM, 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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Fri, Oct 24, 2014 at 1:30 AM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen. [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion I abandoned that approach as cherry-picking started to give complicated conflicts that I could not resolve. Also one particular conflict, the one in the db upgrade script, kept coming back. This has cost me a lot of time for work that was not there to begin with. Hence my big aversion of the forward branches. -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Are we talking about something like what I drew up here?: http://i.imgur.com/UgPtJGY.png In this scheme, the -forward branches are the ones you can directly commit to while their peers without the -forward are the ones that code gets merged to from its corresponding -forward branch. CI is performed on the -forward branches before any merging takes place. The merge recorded concept I put in the diagram refers to the situation where you have a commit on a branch like 4.5, but you do NOT want it to move forward to master. I don't know if Git has such a concept, but SVN calls this kind of a merge merge recording. Merge recording essentially means you do not want those changes brought forward to the specified branch (not now and not with future merges other people or yourself may do). On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, October 23, 2014 1:31 AM To: dev Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: ... 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen. [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Yeah, Daan, the approach you describe sounds like a reasonable substitute for what I have in that diagram. My main concern was CI running before the code was checked into the real branch from the staging branch. On Fri, Oct 24, 2014 at 1:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Are we talking about something like what I drew up here?: http://i.imgur.com/UgPtJGY.png In this scheme, the -forward branches are the ones you can directly commit to while their peers without the -forward are the ones that code gets merged to from its corresponding -forward branch. CI is performed on the -forward branches before any merging takes place. The merge recorded concept I put in the diagram refers to the situation where you have a commit on a branch like 4.5, but you do NOT want it to move forward to master. I don't know if Git has such a concept, but SVN calls this kind of a merge merge recording. Merge recording essentially means you do not want those changes brought forward to the specified branch (not now and not with future merges other people or yourself may do). On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, October 23, 2014 1:31 AM To: dev Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: ... 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen. [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Right, we just need to make sure CI comes into play before the merge. Hence my earlier reply to what Daan mention: My main concern was CI running before the code was checked into the real branch from the staging branch. On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote: On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. CI really needs to happen before the merge occurs, IMO. Backing out merges, in my experience, is incredibly painful. And typically this means that someone else is going to have to clean up the mess after someone merges. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. CI really needs to happen before the merge occurs, IMO. Backing out merges, in my experience, is incredibly painful. And typically this means that someone else is going to have to clean up the mess after someone merges.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
mobile dev with bilingual spelling checker used (read at your own risk) Op 24 okt. 2014 20:30 schreef David Nalley da...@gnsa.us: On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. CI really needs to happen before the merge occurs, IMO. Yes, that is exactly what i am saying Backing out merges, in my experience, is incredibly painful. And typically this means that someone else is going to have to clean up the mess after someone merges. and this is also what is wrong with the forward branches. It happened there as well.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
We do run ci on branches! mobile dev with bilingual spelling checker used (read at your own risk) Op 24 okt. 2014 20:38 schreef Mike Tutkowski mike.tutkow...@solidfire.com : Right, we just need to make sure CI comes into play before the merge. Hence my earlier reply to what Daan mention: My main concern was CI running before the code was checked into the real branch from the staging branch. On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote: On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. CI really needs to happen before the merge occurs, IMO. Backing out merges, in my experience, is incredibly painful. And typically this means that someone else is going to have to clean up the mess after someone merges. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Cool...so, it sounds like any branch we create in the repo will automatically have CI run against it post each commit. How do you know when CI has completed and what the results are? At that point, you could treat your own branch (as Daan says) as the forward branch. Once CI has been successful, you can merge your code to, say, 4.5 (or the RM can). We then need a protocol for when we merge to 4.5 from our own branch, but don't want to have those changes in master. If we do want those changes, of course we can just merge from 4.5 to master. On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: We do run ci on branches! mobile dev with bilingual spelling checker used (read at your own risk) Op 24 okt. 2014 20:38 schreef Mike Tutkowski mike.tutkow...@solidfire.com : Right, we just need to make sure CI comes into play before the merge. Hence my earlier reply to what Daan mention: My main concern was CI running before the code was checked into the real branch from the staging branch. On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote: On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. CI really needs to happen before the merge occurs, IMO. Backing out merges, in my experience, is incredibly painful. And typically this means that someone else is going to have to clean up the mess after someone merges. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
At the moment it must be called 'hotfix/*' or 'bugfix/*'. we should add 'feature/*' to that. On Fri, Oct 24, 2014 at 11:11 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Cool...so, it sounds like any branch we create in the repo will automatically have CI run against it post each commit. How do you know when CI has completed and what the results are? At that point, you could treat your own branch (as Daan says) as the forward branch. Once CI has been successful, you can merge your code to, say, 4.5 (or the RM can). We then need a protocol for when we merge to 4.5 from our own branch, but don't want to have those changes in master. If we do want those changes, of course we can just merge from 4.5 to master. On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: We do run ci on branches! mobile dev with bilingual spelling checker used (read at your own risk) Op 24 okt. 2014 20:38 schreef Mike Tutkowski mike.tutkow...@solidfire.com : Right, we just need to make sure CI comes into play before the merge. Hence my earlier reply to what Daan mention: My main concern was CI running before the code was checked into the real branch from the staging branch. On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote: On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there. CI really needs to happen before the merge occurs, IMO. Backing out merges, in my experience, is incredibly painful. And typically this means that someone else is going to have to clean up the mess after someone merges. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan
RE: [PROPOSAL] Move to github PR only during moratorium on commit
-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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: [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. Agree. Animesh has good point to share here. 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. At any given time, the release branch is hopefully more stable than master (since it’s getting bugfixes/hardening as Animesh shared). So, by merging release branch on master we get all those hardened changes back to master. If we fix things on release branch and keep merging the release branch on master, we fix the issue both on release branch and master branch. The only issue I see is code divergence between release branch and master branch as time passes. 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. Agree, any fix that should not be done on release branch should go in to master. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: ... 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
-Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Thursday, October 23, 2014 1:22 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: [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. Agree. Animesh has good point to share here. 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. At any given time, the release branch is hopefully more stable than master (since it’s getting bugfixes/hardening as Animesh shared). So, by merging release branch on master we get all those hardened changes back to master. If we fix things on release branch and keep merging the release branch on master, we fix the issue both on release branch and master branch. The only issue I see is code divergence between release branch and master branch as time passes. [Animesh] Yes that is correct and that's why we had the forward branches in 4.2 and 4.3 so that commits go into forward branches (really staging) an master and it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and created less confusion 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. Agree, any fix that should not be done on release branch should go in to master. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and- build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack- infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack- training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
-Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, October 23, 2014 1:31 AM To: dev Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: ... 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen. [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Are we talking about something like what I drew up here?: http://i.imgur.com/UgPtJGY.png In this scheme, the -forward branches are the ones you can directly commit to while their peers without the -forward are the ones that code gets merged to from its corresponding -forward branch. CI is performed on the -forward branches before any merging takes place. The merge recorded concept I put in the diagram refers to the situation where you have a commit on a branch like 4.5, but you do NOT want it to move forward to master. I don't know if Git has such a concept, but SVN calls this kind of a merge merge recording. Merge recording essentially means you do not want those changes brought forward to the specified branch (not now and not with future merges other people or yourself may do). On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Thursday, October 23, 2014 1:31 AM To: dev Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: ... 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. By the same logic, if we fix by default on master only, the release branch may miss out commits. I sttrongly disagree with Animesh here and think Rohit is overlooking a simple fact. At the moment the branches are for 'stabalizing'. Fixing on master first is in direct contradiction with that. We have not been stabalizing 4.4. it contains bug that have during the release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't have been allowed to happen. [Animesh] Clearly we have disagreement. To avoid the issue that you mention David had created forward branch for 4.2 and I found it useful and continued with that approach in 4.3. With forward branch which are really staging it was a simple merge of forward back to release branch. The other approach of merging release branch into master work as well but in my opinion keeping master as the default branch (with protection of course ) is simpler to understand and creates less confusion -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Oct 22, 2014, at 1:21 AM, David Nalley da...@gnsa.us wrote: Hi Sebastien: So I like the idea of: 1. Us putting up all inbound code for review. 2. Gating that code on a testing pass 3. Having someone else look at it before committing. I don't think that should mean that all code that works gets an immediate pass. I also don't think that we should have n RMs for branches. It doesn't scale, and it moves us from consensus to authoritarian. I am all for reverting things that break, but think that should be a community wide responsibility, not one or two policemen. I also think this is a huge shift in process. Right now we have 145 open patches on ReviewBoard. We average scores of commits per day; so understand that this is a huge, gigantic shift in how we work. This requires a high level of commitment from everyone, and frankly it's likely to bury TravisCI. I also worry about the effect of this on our ability to timely ship 4.5. We have 14 Critical and blocker bugs for 4.5, and part of me worries that this is a distraction for 4.5 release efforts. Please don't take this as discounting your proposal or your concerns. I don't think that many folks disagrees in principle with the first 3 points above. But timing, and implementation details may be an issue. --David I respectfully disagree with you. I hear your concerns but I feel that we are at a stage where we need drastic measures. I understand this may sound like an authoritarian proposal but this is how I see it, I don't like the way we develop cloudstack and I am not even a software engineer. I am off for 2 weeks, and won't be able to check on this or defend this proposal. -sebastien On Sat, Oct 18, 2014 at 5:00 AM, sebgoa run...@gmail.com wrote: 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Oct 21, 2014, at 6:32 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Code reviews are great. However, we will need to change our behavior quite a bit if code is to make it in within a reasonable amount of time as code reviews today often don't get done in a timely fashion. Just look at it as an incremental step forward. Reviews could just be a ship it, like we see many times on RB. The point is really to track the commits better and have the RMs (whatever many we have), to do the commits and construct the release branches. This would be much better than the free for all we have right now and would redirect development to feature branches and bugfix branches until merged. And fwiw, I do believe that RM is a full time job. In a volunteer community, it's hard to assign work (including code reviews) to people (let alone expect it done on your schedule). This is, of course, different at most of our day jobs where managers are in a position to make sure the community is responsive. On Monday, October 20, 2014, Rajani Karuturi raj...@apache.org wrote: I like the way Stephen split it. Here is my vote. +1 on using github pull requests. +1 on compulsory code reviews and PRs even for committers and CI build pass before merging. +1 on merges from 4.5 to master and no individual commits(or cherry-picks) to the branches +0 on RM for master and commits gated by him. I agree with Stephen that code reviewer should be doing the push. But, I am ok with RM doing it(assuming we have a volunteer ;) ). +1 on any changes independently. ~Rajani On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner stephen.tur...@citrix.com javascript:; wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com javascript:;] Sent: 18 October 2014 10:00 To: dev@cloudstack.apache.org javascript:; 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). 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. 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. 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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Ok, no one says it so let me be the bad guy. rant Nothing will work unless the citrix department in california agrees. They have their in-house legacy proces to change and will not unless they can sell it easily upstream. So whether we make a grand uninfied proposal or take small steps doesn't matter, it must fit their internal political situation. This is very unhealthy. I am not saying that the objections coming from that group are unreasonable every time. Sometimes they were more then other times. I am even sure that they are working on improving as well but this is invisible to the rest of us. A mail every once in a while does not make this visible. The proces of improving the way we work is impaired by it. They to need to make small steps so we can see what is happening and where we are going. Even a grand proposal by Citrix California won't be accepted, because the change will be to big! /rant frustrated conclusion I made some small steps in improving during the 4.4.1 release process. These were largely ignored or reverted in the current branch. unless the current state of 4.5 happens to be very good we are in for a repeat of recent history. /frustrated conclusion You know where to find me, Daan On Tue, Oct 21, 2014 at 6:32 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Code reviews are great. However, we will need to change our behavior quite a bit if code is to make it in within a reasonable amount of time as code reviews today often don't get done in a timely fashion. In a volunteer community, it's hard to assign work (including code reviews) to people (let alone expect it done on your schedule). This is, of course, different at most of our day jobs where managers are in a position to make sure the community is responsive. On Monday, October 20, 2014, Rajani Karuturi raj...@apache.org wrote: I like the way Stephen split it. Here is my vote. +1 on using github pull requests. +1 on compulsory code reviews and PRs even for committers and CI build pass before merging. +1 on merges from 4.5 to master and no individual commits(or cherry-picks) to the branches +0 on RM for master and commits gated by him. I agree with Stephen that code reviewer should be doing the push. But, I am ok with RM doing it(assuming we have a volunteer ;) ). +1 on any changes independently. ~Rajani On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner stephen.tur...@citrix.com javascript:; wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com javascript:;] Sent: 18 October 2014 10:00 To: dev@cloudstack.apache.org javascript:; 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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Oct 21, 2014, at 9:36 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Ok, no one says it so let me be the bad guy. rant Nothing will work unless the citrix department in california agrees. They have their in-house legacy proces to change and will not unless they can sell it easily upstream. So whether we make a grand uninfied proposal or take small steps doesn't matter, it must fit their internal political situation. This is very unhealthy. I am not saying that the objections coming from that group are unreasonable every time. Sometimes they were more then other times. I am even sure that they are working on improving as well but this is invisible to the rest of us. A mail every once in a while does not make this visible. The proces of improving the way we work is impaired by it. They to need to make small steps so we can see what is happening and where we are going. Even a grand proposal by Citrix California won't be accepted, because the change will be to big! /rant frustrated conclusion I made some small steps in improving during the 4.4.1 release process. These were largely ignored or reverted in the current branch. unless the current state of 4.5 happens to be very good we are in for a repeat of recent history. /frustrated conclusion You know where to find me, Daan I will mostly +1 this -sebastien On Tue, Oct 21, 2014 at 6:32 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Code reviews are great. However, we will need to change our behavior quite a bit if code is to make it in within a reasonable amount of time as code reviews today often don't get done in a timely fashion. In a volunteer community, it's hard to assign work (including code reviews) to people (let alone expect it done on your schedule). This is, of course, different at most of our day jobs where managers are in a position to make sure the community is responsive. On Monday, October 20, 2014, Rajani Karuturi raj...@apache.org wrote: I like the way Stephen split it. Here is my vote. +1 on using github pull requests. +1 on compulsory code reviews and PRs even for committers and CI build pass before merging. +1 on merges from 4.5 to master and no individual commits(or cherry-picks) to the branches +0 on RM for master and commits gated by him. I agree with Stephen that code reviewer should be doing the push. But, I am ok with RM doing it(assuming we have a volunteer ;) ). +1 on any changes independently. ~Rajani On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner stephen.tur...@citrix.com javascript:; wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com javascript:;] Sent: 18 October 2014 10:00 To: dev@cloudstack.apache.org javascript:; 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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Hi Sebastien: So I like the idea of: 1. Us putting up all inbound code for review. 2. Gating that code on a testing pass 3. Having someone else look at it before committing. I don't think that should mean that all code that works gets an immediate pass. I also don't think that we should have n RMs for branches. It doesn't scale, and it moves us from consensus to authoritarian. I am all for reverting things that break, but think that should be a community wide responsibility, not one or two policemen. I also think this is a huge shift in process. Right now we have 145 open patches on ReviewBoard. We average scores of commits per day; so understand that this is a huge, gigantic shift in how we work. This requires a high level of commitment from everyone, and frankly it's likely to bury TravisCI. I also worry about the effect of this on our ability to timely ship 4.5. We have 14 Critical and blocker bugs for 4.5, and part of me worries that this is a distraction for 4.5 release efforts. Please don't take this as discounting your proposal or your concerns. I don't think that many folks disagrees in principle with the first 3 points above. But timing, and implementation details may be an issue. --David On Sat, Oct 18, 2014 at 5:00 AM, sebgoa run...@gmail.com wrote: 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/18/2014 11:00 AM, sebgoa wrote: 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: I fully understand the reasoning and I agree that this is the best way forward. Code quality is much more needed then new features. Revert without warning is also just fine. It will take some time to adjust, but this would be a great thing to do. Wido [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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUROXIAAoJEAGbWC3bPspCifwP/1NtM7L61p8YI/W4qn9LH+fs oo5PeLY61IitdDGJoT7DTfiJhCgM4HWYHKyZOUkZLm53wUKbrUuzSVZ6ZIfrlss6 erWIXCHrk2VPzaBX3nyOBzaEdrnLYTlMdJgxHVd5IUq+HBtf3GPQDUHu3EnsNKk4 BP+3fJg5hfIF4jkevXlGebcdsT9CWQIz3Z656Dr1tknYUBlTyM+wBOsp3BhAEWG0 VTC9Gt/YfOo3P3xWEBUZ40GRhd4bM9OaHhiDqN/vz4wKyz7X2//oShudVSTZsrg9 Hm2CYt9W1/TjLEAk87VBvtNyY4U9OaZTnQBK/T+N7uu7E8whFmqffDDWYiSmBt+J UDsYQfn/U/aKqgyMasXRWTF8CxZHRM8YyZzwbrMhVYUPdlsnhUdmzksG7zKwcNjp rpXcS3LkXW6xp0sYp6MWdUp7EVhpDE7q06HiWDONrrKRdyKTxO9P+tWWUJJdVee/ zwb617SIFyDYK9DBKSDSGIdAFE81rl+PBTqPJe2wotJ5KKuRbcVWaqFqvWqmuLxs XiMiB3CduBbLecmyEqa0szQqv9OXRHeNGvrjEM29L7kYSb6Rua05jmTwFXEj+1Ob IxF9wOB/licwfCOE8VSNz8xbiptbtloKhT4OFyliFW/RAuBwQlznus8A9xGVgYz1 gCnEIljSR6Tle3F9kvU7 =MHeW -END PGP SIGNATURE-
RE: [PROPOSAL] Move to github PR only during moratorium on commit
As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 18 October 2014 10:00 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Oct 20, 2014, at 1:51 PM, Stephen Turner stephen.tur...@citrix.com wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. Understood, the idea is to go with this drastic change and as we adjust we can relax a bit this constraint. The benefit is to start controlling what will go in the next release before a release branch is even cut and get all developers (committers or not) to start using feature branches systematically. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 18 October 2014 10:00 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
+1 and small changes should go through even if bigger goals glare on the horizon. On Mon, Oct 20, 2014 at 2:14 PM, sebgoa run...@gmail.com wrote: On Oct 20, 2014, at 1:51 PM, Stephen Turner stephen.tur...@citrix.com wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. Understood, the idea is to go with this drastic change and as we adjust we can relax a bit this constraint. The benefit is to start controlling what will go in the next release before a release branch is even cut and get all developers (committers or not) to start using feature branches systematically. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 18 October 2014 10:00 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
I'm in complete agreement with Stephen on this one. I would be considered the master RM could be overwhelmed with work. Other than that +1. On 20 October 2014 14:13, Daan Hoogland daan.hoogl...@gmail.com wrote: +1 and small changes should go through even if bigger goals glare on the horizon. On Mon, Oct 20, 2014 at 2:14 PM, sebgoa run...@gmail.com wrote: On Oct 20, 2014, at 1:51 PM, Stephen Turner stephen.tur...@citrix.com wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. Understood, the idea is to go with this drastic change and as we adjust we can relax a bit this constraint. The benefit is to start controlling what will go in the next release before a release branch is even cut and get all developers (committers or not) to start using feature branches systematically. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 18 October 2014 10:00 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Sat, Oct 18, 2014 at 11:00 AM, sebgoa run...@gmail.com wrote: 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). 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. 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. 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. I'm +1 to any change that could improve quality, and submitting to github as non-committer is a magnitude faster/easier than RB. -- Erik
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that. From: sebgoa run...@gmail.commailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Saturday, October 18, 2014 at 2:00 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto: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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that. Shouldn't have to, you can still merge/push to the ASF infra repository and only the PR would live on github. It's probably a tad more hassle for the one pushing the commit. I guess Sebastien or Pierre-Luc can chime in with experiences from the doc repos. -- Erik
Re: [PROPOSAL] Move to github PR only during moratorium on commit
No Chiradeep, Pull of the request will still be on the local committer repo and pushed to ASF infra (wip) On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that. From: sebgoa run...@gmail.commailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Saturday, October 18, 2014 at 2:00 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto: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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Thanks. Question for Sebastien then. The argument is that this new proposal will avoid problems such as - broken builds. Presumably this is test failures (don’t recall a compile-time failure). How exactly would this be achieved WITHOUT a CI process? - delayed releases. Not sure how this fixes it. Seems like it is just introducing a bottleneck for the sake of slowing things down? - features merged without warning. Warnings are good. But what does one do with (let’s say a 3-day) warning? One must trust the developer or trust the developer and the CI system. The argument it seems is for a stable master vs a stable release branch. Is that the correct summary? Why not switch to that model on ACS git instead of GitHub? From: Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, October 20, 2014 at 10:34 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit No Chiradeep, Pull of the request will still be on the local committer repo and pushed to ASF infra (wip) On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that. From: sebgoa run...@gmail.commailto:run...@gmail.commailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Saturday, October 18, 2014 at 2:00 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
On Oct 20, 2014, at 8:28 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Thanks. Question for Sebastien then. The argument is that this new proposal will avoid problems such as - broken builds. Presumably this is test failures (don’t recall a compile-time failure). How exactly would this be achieved WITHOUT a CI process? I am not arguing against a CI process. We currently have TravisCI for smoke test and it runs on every commit. It will also run on every PR. So at a minimum when doing a review we can check that smoke tests (and therefore build) pass before merging. We also have Jenkins and if we were to get in the habit of creating branches for every bug/hotfix they would automatically be tested via jenkins as well. My point being that a full fledged CI where we test all combination of hypervisor/storage/network is still way out until we seriously tackle it. This proposal would help us change our commit habits to help reduce release time by better reviewing and merging things. - delayed releases. Not sure how this fixes it. Seems like it is just introducing a bottleneck for the sake of slowing things down? No, it's not for the sake of slowing things down. It will certainly be a bit of a pain at first, but the whole idea is to make releases on time and more easily. Currently we develop on master, since we branch releases off master, each new release is quite divergent from a the previous one, and we re-invest a lot of time from release to release to stabilize them. If we could base a release of a stable master, we could actually *construct* a release, by picking features that are ready and we would have greater confidence that bugs fixed during QA time (in our current process) would actually be in the next release. - features merged without warning. Warnings are good. But what does one do with (let’s say a 3-day) warning? One must trust the developer or trust the developer and the CI system. I don't have a specific example, but we have seen features being merged without tests, uncomplete features being merged and we even have struggled to identified new features that are in a release. At a minimum, this would serve at publicising a features to the whole community. The argument it seems is for a stable master vs a stable release branch. Is that the correct summary? Why not switch to that model on ACS git instead of GitHub? stable is a bit of a blinking word. What I mean when I use stable is that I would like to make sure that master is always in a releasable state, so that we avoid duplicating QA when we prep a release. Say we QA master and we get to a releasable (as in voted release) state, then when we start fixing bugs in the release branch we can cleanly merge those back in master and we have certainty that master will also be releasable. If we keep iterating like this, the next time we branch a release branch, we can merge the features selected for that release and we are done (ideally). Going through github PR gives us a basic review functionality, as well as basic smoke tests. Basically it will gate every commit (for a while), until we get in the habit of committing in the correct place. This is not about questioning committers code quality (while it will help quality by offering a clear review process), it is about changing habits to help with releasing on-time and with transparency on what is in a release. From: Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, October 20, 2014 at 10:34 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit No Chiradeep, Pull of the request will still be on the local committer repo and pushed to ASF infra (wip) On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that. From: sebgoa run...@gmail.commailto:run...@gmail.commailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Saturday, October 18, 2014 at 2:00 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: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
Re: [PROPOSAL] Move to github PR only during moratorium on commit
To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit No Chiradeep, Pull of the request will still be on the local committer repo and pushed to ASF infra (wip) On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: Won’t this proposal make GitHub the canonical repository? I don’t see ASF infra being too happy with that. From: sebgoa run...@gmail.commailto:run...@gmail.commailto: run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org mailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.org Date: Saturday, October 18, 2014 at 2:00 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -- Daan
Re: [PROPOSAL] Move to github PR only during moratorium on commit
I like the way Stephen split it. Here is my vote. +1 on using github pull requests. +1 on compulsory code reviews and PRs even for committers and CI build pass before merging. +1 on merges from 4.5 to master and no individual commits(or cherry-picks) to the branches +0 on RM for master and commits gated by him. I agree with Stephen that code reviewer should be doing the push. But, I am ok with RM doing it(assuming we have a volunteer ;) ). +1 on any changes independently. ~Rajani On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner stephen.tur...@citrix.com wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 18 October 2014 10:00 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Code reviews are great. However, we will need to change our behavior quite a bit if code is to make it in within a reasonable amount of time as code reviews today often don't get done in a timely fashion. In a volunteer community, it's hard to assign work (including code reviews) to people (let alone expect it done on your schedule). This is, of course, different at most of our day jobs where managers are in a position to make sure the community is responsive. On Monday, October 20, 2014, Rajani Karuturi raj...@apache.org wrote: I like the way Stephen split it. Here is my vote. +1 on using github pull requests. +1 on compulsory code reviews and PRs even for committers and CI build pass before merging. +1 on merges from 4.5 to master and no individual commits(or cherry-picks) to the branches +0 on RM for master and commits gated by him. I agree with Stephen that code reviewer should be doing the push. But, I am ok with RM doing it(assuming we have a volunteer ;) ). +1 on any changes independently. ~Rajani On Mon, Oct 20, 2014 at 5:21 PM, Stephen Turner stephen.tur...@citrix.com javascript:; wrote: As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com javascript:;] Sent: 18 October 2014 10:00 To: dev@cloudstack.apache.org javascript:; 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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
[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). 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. 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. 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. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
Re: [PROPOSAL] Move to github PR only during moratorium on commit
Hi, On 18-Oct-2014, at 2:30 pm, sebgoa run...@gmail.com wrote: [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. +1 Much needed and Github is just more fun than RB any day. Merging gives us the benefit of reverting the merge by reverting on the merge commit which is useful to revert a merge that break some functionality and perhaps not the build. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
