You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daan Hoogland <da...@gmail.com> on 2014/10/16 11:34:41 UTC
merging versus cherry-picking
H,
I noticed a lot of commits on master and 4.5 without any links between
them. These could have all been committed on 4.5 and merged back into
master leaving a trail of prove that the same code is in both branches.
It hurts to see this happen. we are at a brink where we can improve on our
way of working. Let's do so. I will do a test merge-back of 4.5 to master
to see how big the damage is.
--
Daan
Re: merging versus cherry-picking
Posted by Daan Hoogland <da...@gmail.com>.
On Thu, Oct 16, 2014 at 11:34 AM, Daan Hoogland <da...@gmail.com>
wrote:
...
> I will do a test merge-back of 4.5 to master to see how big the damage is.
>
So I did locally and found:
commit 148efbb73f0e084614eff62f48ea9fa964c64da8
Merge: 1f8cf0b 420d4e0
Author: Daan Hoogland <da...@onecht.net>
Date: Thu Oct 16 12:29:37 2014 +0200
Merge remote-tracking branch 'origin/4.5' into merge-master
Conflicts:
engine/schema/src/com/cloud/upgrade/dao/Upgrade441to450.java
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BaremetalManagerImpl.java
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BaremetalVlanManager.java
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BaremetalVlanManagerImpl.java
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalKickStartServiceImpl.java
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
setup/db/db/schema-441to450.sql
test/integration/component/test_deploy_vgpu_vm.py
tools/marvin/marvin/config/test_data.py
It seems we can still go ahead if I push this.
--
Daan
Re: merging versus cherry-picking
Posted by Daan Hoogland <da...@gmail.com>.
+1
On Thu, Oct 16, 2014 at 12:02 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Oct 16, 2014, at 11:34 AM, Daan Hoogland <da...@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.
> ----
>
I don't like your proposal but agree that such a drastic step is needed. I
will yield to it in favour of a journey towards quicker release cycles.
>
> This is drastic and I am sure some folks will not like it, but here is my
> justification for such a measure:
>
> 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.
>
> -sebastien
>
>
--
Daan
Re: merging versus cherry-picking
Posted by Rajani Karuturi <ra...@apache.org>.
+1 on merging(and the proposal).
Unlike the belief that merging adds to dev time it actually makes life
easier to track a commit (after all, it has the same number of commands and
the same conflicts as cherry-pick :) )
We should also define merge strategy for LTS(4.3 and 4.4) branches.
~Rajani
On Thu, Oct 16, 2014 at 4:27 PM, Rohit Yadav <ro...@shapeblue.com>
wrote:
> Hi,
>
> On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
>
> We get the free TravisCI smoke checks and personally I find it more
> pleasant to view the diff, review on PR.
>
> > This is drastic and I am sure some folks will not like it, but here is
> my justification for such a measure:
> >
> > 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.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://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: merging versus cherry-picking
Posted by Daan Hoogland <da...@gmail.com>.
like you comments Stephen
+1
Daan
On Mon, Oct 20, 2014 at 1:25 PM, Stephen Turner <St...@citrix.com>
wrote:
> I am +1 on using github.
>
> 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 for the moment.
>
> 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: David Nalley [mailto:david@gnsa.us]
> Sent: 17 October 2014 01:02
> To: dev@cloudstack.apache.org
> Subject: Re: merging versus cherry-picking
>
> I think this needs it's own thread as a [PROPOSAL] So a couple of comments:
>
> 1. I think we need to do things in a uniform way. Having patches committed
> directly, having patches hit RB and having patches hit GH is fail.
> 2. I think we should gate patches, even from committers. I'd personally
> like to see ALL code pass a comprehensive testing regimen, as well as be
> individually reviewed by a committer. That said - I'd rather not let the
> perfect be the enemy of the good. Some testing is better than none.
>
> On Thu, Oct 16, 2014 at 3:23 PM, sebgoa <ru...@gmail.com> wrote:
> >
> > On Oct 16, 2014, at 8:08 PM, Sheng Yang <sh...@yasker.org> wrote:
> >
> >> I totally agree that we should have some staging tree for this
> >> purpose. But I would prefer deploying gerrit on this rather than
> >> using github. Also, using gerrit would make it possible to host our
> >> own Jenkins instance for testing, rather than depends on TravisCI
> >> which is very limited and shared across all the apache projects as I
> heard.
> >
> > Ok so looks like you are +1 for the general direction.
>
> I also agree with this general direction.
>
> >
> > This is going to be a several steps process. While gerrit may end up
> > being the solution, right now it would require finding infra,
> > installing software, learning it for those who have not used it yet
> > etc…
> >
>
> I also have a preference for something more full featured than what we get
> with GH PR and Travis CI - but frankly it's still better than what we have
> now. It might be worthwhile to look into [1] which might allow us to use
> our existing Jenkins instance in the short term. I know that Brooklyn is
> already using this service, and perhaps others. Gerrit is far more full
> featured - and I can certainly see us wanting that (as well as a number of
> other communities at the ASF.
>
> > Moving to github PR with a moratorium on master and release branch is
> only a matter of agreement that will make us adopt new commit habits. there
> is no change of infra/software needed, hence an *easy* step, we just needs
> +1. Once we get to a better state of affairs we can improve our infra and
> processes with other soft.
> >
> >>
>
> So moratorium on unreviewed/untested patches = good. Is there a community
> aspect to people effectively working in forks of our code base in isolation
> rather than in feature branches in our main code base? (I ask because the
> easiest method for using GH PR is to use your own fork of the repo. We
> could have contribs pushed to a feature branch still)
>
>
> [1] https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>
--
Daan
RE: merging versus cherry-picking
Posted by Stephen Turner <St...@citrix.com>.
I am +1 on using github.
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 for the moment.
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: David Nalley [mailto:david@gnsa.us]
Sent: 17 October 2014 01:02
To: dev@cloudstack.apache.org
Subject: Re: merging versus cherry-picking
I think this needs it's own thread as a [PROPOSAL] So a couple of comments:
1. I think we need to do things in a uniform way. Having patches committed directly, having patches hit RB and having patches hit GH is fail.
2. I think we should gate patches, even from committers. I'd personally like to see ALL code pass a comprehensive testing regimen, as well as be individually reviewed by a committer. That said - I'd rather not let the perfect be the enemy of the good. Some testing is better than none.
On Thu, Oct 16, 2014 at 3:23 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Oct 16, 2014, at 8:08 PM, Sheng Yang <sh...@yasker.org> wrote:
>
>> I totally agree that we should have some staging tree for this
>> purpose. But I would prefer deploying gerrit on this rather than
>> using github. Also, using gerrit would make it possible to host our
>> own Jenkins instance for testing, rather than depends on TravisCI
>> which is very limited and shared across all the apache projects as I heard.
>
> Ok so looks like you are +1 for the general direction.
I also agree with this general direction.
>
> This is going to be a several steps process. While gerrit may end up
> being the solution, right now it would require finding infra,
> installing software, learning it for those who have not used it yet
> etc…
>
I also have a preference for something more full featured than what we get with GH PR and Travis CI - but frankly it's still better than what we have now. It might be worthwhile to look into [1] which might allow us to use our existing Jenkins instance in the short term. I know that Brooklyn is already using this service, and perhaps others. Gerrit is far more full featured - and I can certainly see us wanting that (as well as a number of other communities at the ASF.
> Moving to github PR with a moratorium on master and release branch is only a matter of agreement that will make us adopt new commit habits. there is no change of infra/software needed, hence an *easy* step, we just needs +1. Once we get to a better state of affairs we can improve our infra and processes with other soft.
>
>>
So moratorium on unreviewed/untested patches = good. Is there a community aspect to people effectively working in forks of our code base in isolation rather than in feature branches in our main code base? (I ask because the easiest method for using GH PR is to use your own fork of the repo. We could have contribs pushed to a feature branch still)
[1] https://blogs.apache.org/infra/entry/github_pull_request_builds_now
Re: merging versus cherry-picking
Posted by David Nalley <da...@gnsa.us>.
I think this needs it's own thread as a [PROPOSAL]
So a couple of comments:
1. I think we need to do things in a uniform way. Having patches
committed directly, having patches hit RB and having patches hit GH is
fail.
2. I think we should gate patches, even from committers. I'd
personally like to see ALL code pass a comprehensive testing regimen,
as well as be individually reviewed by a committer. That said - I'd
rather not let the perfect be the enemy of the good. Some testing is
better than none.
On Thu, Oct 16, 2014 at 3:23 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Oct 16, 2014, at 8:08 PM, Sheng Yang <sh...@yasker.org> wrote:
>
>> I totally agree that we should have some staging tree for this purpose. But
>> I would prefer deploying gerrit on this rather than using github. Also,
>> using gerrit would make it possible to host our own Jenkins instance for
>> testing, rather than depends on TravisCI which is very limited and shared
>> across all the apache projects as I heard.
>
> Ok so looks like you are +1 for the general direction.
I also agree with this general direction.
>
> This is going to be a several steps process. While gerrit may end up being the solution, right now it would require finding infra, installing software, learning it for those who have not used it yet etc…
>
I also have a preference for something more full featured than what we
get with GH PR and Travis CI - but frankly it's still better than what
we have now. It might be worthwhile to look into [1] which might allow
us to use our existing Jenkins instance in the short term. I know that
Brooklyn is already using this service, and perhaps others. Gerrit is
far more full featured - and I can certainly see us wanting that (as
well as a number of other communities at the ASF.
> Moving to github PR with a moratorium on master and release branch is only a matter of agreement that will make us adopt new commit habits. there is no change of infra/software needed, hence an *easy* step, we just needs +1. Once we get to a better state of affairs we can improve our infra and processes with other soft.
>
>>
So moratorium on unreviewed/untested patches = good. Is there a
community aspect to people effectively working in forks of our code
base in isolation rather than in feature branches in our main code
base? (I ask because the easiest method for using GH PR is to use your
own fork of the repo. We could have contribs pushed to a feature
branch still)
[1] https://blogs.apache.org/infra/entry/github_pull_request_builds_now
Re: merging versus cherry-picking
Posted by sebgoa <ru...@gmail.com>.
On Oct 16, 2014, at 8:08 PM, Sheng Yang <sh...@yasker.org> wrote:
> I totally agree that we should have some staging tree for this purpose. But
> I would prefer deploying gerrit on this rather than using github. Also,
> using gerrit would make it possible to host our own Jenkins instance for
> testing, rather than depends on TravisCI which is very limited and shared
> across all the apache projects as I heard.
Ok so looks like you are +1 for the general direction.
This is going to be a several steps process. While gerrit may end up being the solution, right now it would require finding infra, installing software, learning it for those who have not used it yet etc…
Moving to github PR with a moratorium on master and release branch is only a matter of agreement that will make us adopt new commit habits. there is no change of infra/software needed, hence an *easy* step, we just needs +1. Once we get to a better state of affairs we can improve our infra and processes with other soft.
>
> I also notice that before 4.5 cut Daan merge a large refactor of VR. I
> thought it's feature freeze now?
no, it was merged after the cut and is not in 4.5. This actually serves as a great example, there was several PR for this, with review and transparency due to the github notifications. I would like to see all our features being discussed and merged like this (at least for the time being).
>
> --Sheng
> On Oct 16, 2014 7:14 AM, "Giles Sirett" <gi...@shapeblue.com> wrote:
>
>> +1 to Sebastians proposal
>>
>>
>> Kind Regards
>> Giles
>>
>> D: +44 20 3603 0541 | M: +44 796 111 2055
>> Giles.Sirett@shapeblue.com
>>
>>
>>
>>
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>> Sent: 16 October 2014 11:58
>> To: dev@cloudstack.apache.org
>> Subject: Re: merging versus cherry-picking
>>
>> Hi,
>>
>> On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
>>
>> We get the free TravisCI smoke checks and personally I find it more
>> pleasant to view the diff, review on PR.
>>
>>> This is drastic and I am sure some folks will not like it, but here is
>> my justification for such a measure:
>>>
>>> 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.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://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.
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://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: merging versus cherry-picking
Posted by Daan Hoogland <da...@gmail.com>.
Sheng, I merged after the branch not before. Did this end up in 4.5?
On Thu, Oct 16, 2014 at 8:08 PM, Sheng Yang <sh...@yasker.org> wrote:
> I totally agree that we should have some staging tree for this purpose. But
> I would prefer deploying gerrit on this rather than using github. Also,
> using gerrit would make it possible to host our own Jenkins instance for
> testing, rather than depends on TravisCI which is very limited and shared
> across all the apache projects as I heard.
>
> I also notice that before 4.5 cut Daan merge a large refactor of VR. I
> thought it's feature freeze now?
>
> --Sheng
> On Oct 16, 2014 7:14 AM, "Giles Sirett" <gi...@shapeblue.com>
> wrote:
>
> > +1 to Sebastians proposal
> >
> >
> > Kind Regards
> > Giles
> >
> > D: +44 20 3603 0541 | M: +44 796 111 2055
> > Giles.Sirett@shapeblue.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> > Sent: 16 October 2014 11:58
> > To: dev@cloudstack.apache.org
> > Subject: Re: merging versus cherry-picking
> >
> > Hi,
> >
> > On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
> >
> > We get the free TravisCI smoke checks and personally I find it more
> > pleasant to view the diff, review on PR.
> >
> > > This is drastic and I am sure some folks will not like it, but here is
> > my justification for such a measure:
> > >
> > > 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.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> >
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> > http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://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.
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> > http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://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.
> >
>
--
Daan
RE: merging versus cherry-picking
Posted by Sheng Yang <sh...@yasker.org>.
Oh, sorry Daan, seems I am a little out dated. Just found 4.5 has been
branched without the refactor.
--Sheng
On Oct 16, 2014 11:08 AM, "Sheng Yang" <sh...@yasker.org> wrote:
> I totally agree that we should have some staging tree for this purpose.
> But I would prefer deploying gerrit on this rather than using github. Also,
> using gerrit would make it possible to host our own Jenkins instance for
> testing, rather than depends on TravisCI which is very limited and shared
> across all the apache projects as I heard.
>
> I also notice that before 4.5 cut Daan merge a large refactor of VR. I
> thought it's feature freeze now?
>
> --Sheng
> On Oct 16, 2014 7:14 AM, "Giles Sirett" <gi...@shapeblue.com>
> wrote:
>
>> +1 to Sebastians proposal
>>
>>
>> Kind Regards
>> Giles
>>
>> D: +44 20 3603 0541 | M: +44 796 111 2055
>> Giles.Sirett@shapeblue.com
>>
>>
>>
>>
>> -----Original Message-----
>> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
>> Sent: 16 October 2014 11:58
>> To: dev@cloudstack.apache.org
>> Subject: Re: merging versus cherry-picking
>>
>> Hi,
>>
>> On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
>>
>> We get the free TravisCI smoke checks and personally I find it more
>> pleasant to view the diff, review on PR.
>>
>> > This is drastic and I am sure some folks will not like it, but here is
>> my justification for such a measure:
>> >
>> > 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.
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://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.
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build<
>> http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<
>> http://shapeblue.com/cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<
>> http://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: merging versus cherry-picking
Posted by Sheng Yang <sh...@yasker.org>.
I totally agree that we should have some staging tree for this purpose. But
I would prefer deploying gerrit on this rather than using github. Also,
using gerrit would make it possible to host our own Jenkins instance for
testing, rather than depends on TravisCI which is very limited and shared
across all the apache projects as I heard.
I also notice that before 4.5 cut Daan merge a large refactor of VR. I
thought it's feature freeze now?
--Sheng
On Oct 16, 2014 7:14 AM, "Giles Sirett" <gi...@shapeblue.com> wrote:
> +1 to Sebastians proposal
>
>
> Kind Regards
> Giles
>
> D: +44 20 3603 0541 | M: +44 796 111 2055
> Giles.Sirett@shapeblue.com
>
>
>
>
> -----Original Message-----
> From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
> Sent: 16 October 2014 11:58
> To: dev@cloudstack.apache.org
> Subject: Re: merging versus cherry-picking
>
> Hi,
>
> On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
>
> We get the free TravisCI smoke checks and personally I find it more
> pleasant to view the diff, review on PR.
>
> > This is drastic and I am sure some folks will not like it, but here is
> my justification for such a measure:
> >
> > 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.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://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.
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://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: merging versus cherry-picking
Posted by Giles Sirett <gi...@shapeblue.com>.
+1 to Sebastians proposal
Kind Regards
Giles
D: +44 20 3603 0541 | M: +44 796 111 2055
Giles.Sirett@shapeblue.com
-----Original Message-----
From: Rohit Yadav [mailto:rohit.yadav@shapeblue.com]
Sent: 16 October 2014 11:58
To: dev@cloudstack.apache.org
Subject: Re: merging versus cherry-picking
Hi,
On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
We get the free TravisCI smoke checks and personally I find it more pleasant to view the diff, review on PR.
> This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
>
> 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.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://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.
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://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: merging versus cherry-picking
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi,
On 16-Oct-2014, at 3:32 pm, sebgoa <ru...@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
We get the free TravisCI smoke checks and personally I find it more pleasant to view the diff, review on PR.
> This is drastic and I am sure some folks will not like it, but here is my justification for such a measure:
>
> 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.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://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: merging versus cherry-picking
Posted by sebgoa <ru...@gmail.com>.
On Oct 16, 2014, at 11:34 AM, Daan Hoogland <da...@gmail.com> wrote:
> H,
>
> I noticed a lot of commits on master and 4.5 without any links between
> them. These could have all been committed on 4.5 and merged back into
> master leaving a trail of prove that the same code is in both branches.
>
> It hurts to see this happen. we are at a brink where we can improve on our
> way of working. Let's do so. I will do a test merge-back of 4.5 to master
> to see how big the damage is.
>
> --
> Daan
Daan I am +1000 with you on this, we need to come together as a community and change these practices.
I would like to make one clear proposal to move us forward (outside of this thread if I see that a few folks agree).
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:
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.
-sebastien