You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Rajani Karuturi <ra...@apache.org> on 2015/09/16 08:17:55 UTC

[PROPOSAL] stable master and 4.6 release

Hi all,
There is little progress on 4.6 blockers this week. To release 4.6, we all
should come together and fix the blockers. In recent days, master has
broken multiple times with compilation failures/regressions. If master
breaks, time spent on figuring out what happened and fixing it is time
*not* spent on 4.6.

Here is what we propose:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.
2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests. Until we
have a real hypervisor CI in place, manually testing the PR is a must.
Also, LGTM(or +1) should be accompanied with whats tested and why you are
giving LGTM.

Let us all work together on getting 4.6 out.

Thanks

Regards from the 4.6 RMs,
Remi and Rajani.

On Thu, Sep 10, 2015 at 2:52 PM, Remi Bergsma <RB...@schubergphilis.com>
wrote:

> Hi all,
>
>
> A lot of work is being done to make 4.6 ready for a release. It's great to
> see it's getting better every day!
>
>
> Today Rajani and myself looked at all blocker and critical issues on 4.6.
> We decided to bump some of them to blocker. Two more issues need to
> verified against current master. In case still broken, they will be marked
> blocker as well. This means we'll have 6-8 blocker issues to resolve. Most
> of them are virtual router related and we feel we cannot do a RC without
> properly fixing them.
>
>
> If you have some time, please:
>
>
> Look at the 4.6 release dashboard:
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
>
>
> Fix one of the blockers (or critical issues):
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-8697?filter=12332940
>
>
> It also helps if people help reviewing PRs:
>
> https://github.com/apache/cloudstack/pulls
>
>
> Apart from these issues, 4.6 (aka master) is pretty stable. Feel free to
> test-drive it and verify your key functionality.
>
>
> Thanks!
>
>
> Regards from the 4.6 RMs,
>
>
> Rajani / Remi
>
>

Re: [PROPOSAL] stable master and 4.6 release

Posted by Wilder Rodrigues <WR...@schubergphilis.com>.

I just replied the other email about the VRs, where I actually mentioned the current mess that our github is due to the number of PRs and lack of proper reviews.

So, +100 for that approach! If one cannot test a PR, so do not LGTM it!

I would also add that a PR shall contain:

1. Jira ticket
2. Proper description of what it fixes/improves
3. Unit and/or Integration tests
4. And was tested by the committer!!

Although we already said that, I now feel the need to repeat it.

Cheers,
Wilder

On 16 Sep 2015, at 09:15, Miguel Ferreira <MF...@schubergphilis.com>> wrote:

I totally agree with this proposal.

By the way, until there is a reliable CI build, PR reviews should always follow point 2.

Cheers,
\ Miguel Ferreira
mferreira@schubergphilis.com<ma...@schubergphilis.com>

On 16 Sep 2015, at 08:17, Rajani Karuturi <ra...@apache.org>> wrote:

Hi all,
There is little progress on 4.6 blockers this week. To release 4.6, we all
should come together and fix the blockers. In recent days, master has
broken multiple times with compilation failures/regressions. If master
breaks, time spent on figuring out what happened and fixing it is time
*not* spent on 4.6.

Here is what we propose:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.
2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests. Until we
have a real hypervisor CI in place, manually testing the PR is a must.
Also, LGTM(or +1) should be accompanied with whats tested and why you are
giving LGTM.

Let us all work together on getting 4.6 out.

Thanks

Regards from the 4.6 RMs,
Remi and Rajani.

On Thu, Sep 10, 2015 at 2:52 PM, Remi Bergsma <RB...@schubergphilis.com>>
wrote:

Hi all,

A lot of work is being done to make 4.6 ready for a release. It's great to
see it's getting better every day!

Today Rajani and myself looked at all blocker and critical issues on 4.6.
We decided to bump some of them to blocker. Two more issues need to
verified against current master. In case still broken, they will be marked
blocker as well. This means we'll have 6-8 blocker issues to resolve. Most
of them are virtual router related and we feel we cannot do a RC without
properly fixing them.

If you have some time, please:

Look at the 4.6 release dashboard:

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765

Fix one of the blockers (or critical issues):

https://issues.apache.org/jira/browse/CLOUDSTACK-8697?filter=12332940

It also helps if people help reviewing PRs:

https://github.com/apache/cloudstack/pulls

Apart from these issues, 4.6 (aka master) is pretty stable. Feel free to
test-drive it and verify your key functionality.

Thanks!

Regards from the 4.6 RMs,

Rajani / Remi

Re: [PROPOSAL] stable master and 4.6 release

Posted by Miguel Ferreira <MF...@schubergphilis.com>.

I totally agree with this proposal.

By the way, until there is a reliable CI build, PR reviews should always follow point 2.

Cheers,
\ Miguel Ferreira
   mferreira@schubergphilis.com<ma...@schubergphilis.com>




On 16 Sep 2015, at 08:17, Rajani Karuturi <ra...@apache.org>> wrote:

Hi all,
There is little progress on 4.6 blockers this week. To release 4.6, we all
should come together and fix the blockers. In recent days, master has
broken multiple times with compilation failures/regressions. If master
breaks, time spent on figuring out what happened and fixing it is time
*not* spent on 4.6.

Here is what we propose:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.
2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests. Until we
have a real hypervisor CI in place, manually testing the PR is a must.
Also, LGTM(or +1) should be accompanied with whats tested and why you are
giving LGTM.

Let us all work together on getting 4.6 out.

Thanks

Regards from the 4.6 RMs,
Remi and Rajani.



On Thu, Sep 10, 2015 at 2:52 PM, Remi Bergsma <RB...@schubergphilis.com>>
wrote:

Hi all,


A lot of work is being done to make 4.6 ready for a release. It's great to
see it's getting better every day!


Today Rajani and myself looked at all blocker and critical issues on 4.6.
We decided to bump some of them to blocker. Two more issues need to
verified against current master. In case still broken, they will be marked
blocker as well. This means we'll have 6-8 blocker issues to resolve. Most
of them are virtual router related and we feel we cannot do a RC without
properly fixing them.


If you have some time, please:


Look at the 4.6 release dashboard:

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765


Fix one of the blockers (or critical issues):

https://issues.apache.org/jira/browse/CLOUDSTACK-8697?filter=12332940


It also helps if people help reviewing PRs:

https://github.com/apache/cloudstack/pulls


Apart from these issues, 4.6 (aka master) is pretty stable. Feel free to
test-drive it and verify your key functionality.


Thanks!


Regards from the 4.6 RMs,


Rajani / Remi

Re: [PROPOSAL] stable master and 4.6 release

Posted by Daan Hoogland <da...@gmail.com>.

I agree with our esteemed RMs and want to add that it might be usefull to
mark any PR with [4.6] or [future] so it is clear to everybody what it is
intended for.

On Wed, Sep 16, 2015 at 8:17 AM, Rajani Karuturi <ra...@apache.org> wrote:

> Hi all,
> There is little progress on 4.6 blockers this week. To release 4.6, we all
> should come together and fix the blockers. In recent days, master has
> broken multiple times with compilation failures/regressions. If master
> breaks, time spent on figuring out what happened and fixing it is time
> *not* spent on 4.6.
>
> Here is what we propose:
>
> 1. Only BLOCKER fixes to master. If there's something else that needs to
> get in, it can be discussed with the RMs on a case-by-case basis.
> 2. Atleast one of the reviewers of a PR should do the actual tests. We do
> not have good CI in place and travis just does simulator tests. Until we
> have a real hypervisor CI in place, manually testing the PR is a must.
> Also, LGTM(or +1) should be accompanied with whats tested and why you are
> giving LGTM.
>
> Let us all work together on getting 4.6 out.
>
> Thanks
>
> Regards from the 4.6 RMs,
> Remi and Rajani.
>
>
>
> On Thu, Sep 10, 2015 at 2:52 PM, Remi Bergsma <RBergsma@schubergphilis.com
> >
> wrote:
>
> > Hi all,
> >
> >
> > A lot of work is being done to make 4.6 ready for a release. It's great
> to
> > see it's getting better every day!
> >
> >
> > Today Rajani and myself looked at all blocker and critical issues on 4.6.
> > We decided to bump some of them to blocker. Two more issues need to
> > verified against current master. In case still broken, they will be
> marked
> > blocker as well. This means we'll have 6-8 blocker issues to resolve.
> Most
> > of them are virtual router related and we feel we cannot do a RC without
> > properly fixing them.
> >
> >
> > If you have some time, please:
> >
> >
> > Look at the 4.6 release dashboard:
> >
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
> >
> >
> > Fix one of the blockers (or critical issues):
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-8697?filter=12332940
> >
> >
> > It also helps if people help reviewing PRs:
> >
> > https://github.com/apache/cloudstack/pulls
> >
> >
> > Apart from these issues, 4.6 (aka master) is pretty stable. Feel free to
> > test-drive it and verify your key functionality.
> >
> >
> > Thanks!
> >
> >
> > Regards from the 4.6 RMs,
> >
> >
> > Rajani / Remi
> >
> >
>



-- 
Daan

Re: [PROPOSAL] stable master and 4.6 release

Posted by Wilder Rodrigues <WR...@schubergphilis.com>.

Then we create a 4.6.0 branch, fix all of it and allow people to continue to merge broken code on master. Once we merge 4.6 back to master, most probably the 4.6 stuff won’t work anymore. I have seen it before.

I would still say +1 for the freeze and suggest that we get the contributors aligned on the procedures. If a contributor doesn’t have time to:

1. Jira ticket
2. Proper description of what it fixes/improves
3. Unit and/or Integration tests
4. Test the fix + other basic features

So what is the point in contributing? It brings a burden to the whole community.

If ACS wouldn’t be so tightly couple, perhaps we would care a bit less about the contributions that break stuff. However, when a simple change on a HyperV class - which is not even used in our infrastructure - breaks the hell out of ACS, yes.. we have to be a bit more careful about the code we get in.

When we have a proper CI in place, we can be a bit more soft on the rules.

Cheers,
Wilder

On 16 Sep 2015, at 09:38, Rohit Yadav <ro...@shapeblue.com>> wrote:

On 16-Sep-2015, at 11:47 am, Rajani Karuturi <ra...@apache.org>> wrote:

Here is what we propose:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.

-1 -ish
What you’re effectively saying is to freeze/block master from new changes until 4.6.0 releases which could take anywhere from one week to many weeks. In reality that may be undesirable and can contribute to loss of developer productivity time.

Few suggestions, though I’m not sure that best way to go forward: why not create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively, create a development branch on which development can continue and we merge it back to master when that branch is stable enough and 4.6.0 has released?

2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests.

+1 some of us talking in the background to setup an automated QA system to use existing marvin tests to do long running integration tests but other than Travis or Jenkins (b.a.o) we don’t have anything.

Until we
have a real hypervisor CI in place, manually testing the PR is a must.
Also, LGTM(or +1) should be accompanied with whats tested and why you are
giving LGTM.

+1 at least one person other than the author should have run the PR and tested it manually or otherwise to increase reliance of the patch quality.

Regards,
Rohit Yadav
Software Architect, ShapeBlue

M. +91 88 262 30892 | rohit.yadav@shapeblue.com<ma...@shapeblue.com>
Blog: bhaisaab.org<http://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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
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: [PROPOSAL] stable master and 4.6 release

Posted by Sebastien Goasguen <ru...@gmail.com>.

> On Sep 16, 2015, at 9:58 AM, Daan Hoogland <da...@gmail.com> wrote:
> 
> On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> 
>> 1. Only BLOCKER fixes to master. If there's something else that needs to
>> get in, it can be discussed with the RMs on a case-by-case basis.
>> 
>> 
>> -1 -ish
>> What you’re effectively saying is to freeze/block master from new changes
>> until 4.6.0 releases which could take anywhere from one week to many weeks.
>> In reality that may be undesirable and can contribute to loss of developer
>> productivity time.
>> 
> agree and
> 

Since we are so close to 4.6, it seems freezing it is totally legitimate.
You can keep on working on your own branch and bring master changes in as they are made.
Once 4.6.0 is out, you can submit your PR and merge back in master...

I don’t think this slows you down, it just delays your changes to get into master.

> 
>> 
>> Few suggestions, though I’m not sure that best way to go forward: why not
>> create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively,
>> create a development branch on which development can continue and we merge
>> it back to master when that branch is stable enough and 4.6.0 has released?
>> 
> I don't feel we should create a developer branch, branching 4.6.0 now and
> fixing blockers there to merge them back to master as they are fixed seems
> the way to go to me.
> 
> 
> 
>> 
>> 2. Atleast one of the reviewers of a PR should do the actual tests. We do
>> not have good CI in place and travis just does simulator tests.
>> 
>> 
>> +1 some of us talking in the background to setup an automated QA system to
>> use existing marvin tests to do long running integration tests but other
>> than Travis or Jenkins (b.a.o) we don’t have anything.
>> 
> I hate this but still +1 (CI is/should be there so we don't need this)
> 
> 
> 
> -- 
> Daan

Re: [PROPOSAL] stable master and 4.6 release

Posted by Remi Bergsma <RB...@schubergphilis.com>.

If we all go for it, fix the blocker issues and test 4.6, then we should be able to do it! The CCCEU conference is in ~4 weeks, seems like a great deadline to work towards. But again, we all need to work together to make it happen.

Let’s not forget that making master stable is hard. Just as hard as it used to be in a release branch. Once we achieve a stable master, we need to keep it that wat which means we need to improve Travis and Jenkins so that at PR review time we get the right feedback from the automated systems. Until that is in place, we should be extra careful and show each other how things are tested and reviewed. Once master is stable and 4.6 is out, merging new features and prepping 4.7 should be a lot easier.

Let’s focus on 4.6 and make it a great release!

Regards,
Remi



From: Rohit Yadav
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
Date: Wednesday 16 September 2015 10:07
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
Subject: Re: [PROPOSAL] stable master and 4.6 release

Based on some discussion from slack, I think there is no harm in experimenting this for let’s say 2-4 weeks; at worst we would have blocked people from merging new features etc.

Remi/Rajani - do you think we can pull this off (fix blockers and do a 4.6.0 release) in next 2-4 weeks?

On 16-Sep-2015, at 1:28 pm, Daan Hoogland <da...@gmail.com>> wrote:

On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav <ro...@shapeblue.com>>
wrote:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.


-1 -ish
What you’re effectively saying is to freeze/block master from new changes
until 4.6.0 releases which could take anywhere from one week to many weeks.
In reality that may be undesirable and can contribute to loss of developer
productivity time.

agree and



Few suggestions, though I’m not sure that best way to go forward: why not
create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively,
create a development branch on which development can continue and we merge
it back to master when that branch is stable enough and 4.6.0 has released?

I don't feel we should create a developer branch, branching 4.6.0 now and
fixing blockers there to merge them back to master as they are fixed seems
the way to go to me.




2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests.


+1 some of us talking in the background to setup an automated QA system to
use existing marvin tests to do long running integration tests but other
than Travis or Jenkins (b.a.o) we don’t have anything.

I hate this but still +1 (CI is/should be there so we don't need this)



--
Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue


[cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A]


M. +91 88 262 30892 | rohit.yadav@shapeblue.com<ma...@shapeblue.com>
Blog: bhaisaab.org<http://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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
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: [PROPOSAL] stable master and 4.6 release

Posted by Daan Hoogland <da...@gmail.com>.

I think you are being an optimist saying 2-4 weeks but I second the
attempt. +1

On Wed, Sep 16, 2015 at 10:07 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> Based on some discussion from slack, I think there is no harm in
> experimenting this for let’s say 2-4 weeks; at worst we would have blocked
> people from merging new features etc.
>
> Remi/Rajani - do you think we can pull this off (fix blockers and do a
> 4.6.0 release) in next 2-4 weeks?
>
> On 16-Sep-2015, at 1:28 pm, Daan Hoogland <da...@gmail.com> wrote:
>
> On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav <ro...@shapeblue.com>
> wrote:
>
> 1. Only BLOCKER fixes to master. If there's something else that needs to
> get in, it can be discussed with the RMs on a case-by-case basis.
>
>
> -1 -ish
> What you’re effectively saying is to freeze/block master from new changes
> until 4.6.0 releases which could take anywhere from one week to many weeks.
> In reality that may be undesirable and can contribute to loss of developer
> productivity time.
>
> agree and
>
>
>
> Few suggestions, though I’m not sure that best way to go forward: why not
> create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively,
> create a development branch on which development can continue and we merge
> it back to master when that branch is stable enough and 4.6.0 has released?
>
> I don't feel we should create a developer branch, branching 4.6.0 now and
> fixing blockers there to merge them back to master as they are fixed seems
> the way to go to me.
> 
>
>
>
> 2. Atleast one of the reviewers of a PR should do the actual tests. We do
> not have good CI in place and travis just does simulator tests.
>
>
> +1 some of us talking in the background to setup an automated QA system to
> use existing marvin tests to do long running integration tests but other
> than Travis or Jenkins (b.a.o) we don’t have anything.
>
> I hate this but still +1 (CI is/should be there so we don't need this)
>
>
>
> --
> Daan
>
>
> 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 Software Engineering
> <http://shapeblue.com/cloudstack-software-engineering/>
> 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: [PROPOSAL] stable master and 4.6 release

Posted by Rohit Yadav <ro...@shapeblue.com>.

Based on some discussion from slack, I think there is no harm in experimenting this for let’s say 2-4 weeks; at worst we would have blocked people from merging new features etc.

Remi/Rajani - do you think we can pull this off (fix blockers and do a 4.6.0 release) in next 2-4 weeks?

On 16-Sep-2015, at 1:28 pm, Daan Hoogland <da...@gmail.com>> wrote:

On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav <ro...@shapeblue.com>>
wrote:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.

-1 -ish
What you’re effectively saying is to freeze/block master from new changes
until 4.6.0 releases which could take anywhere from one week to many weeks.
In reality that may be undesirable and can contribute to loss of developer
productivity time.

agree and

Few suggestions, though I’m not sure that best way to go forward: why not
create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively,
create a development branch on which development can continue and we merge
it back to master when that branch is stable enough and 4.6.0 has released?

I don't feel we should create a developer branch, branching 4.6.0 now and
fixing blockers there to merge them back to master as they are fixed seems
the way to go to me.

2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests.

+1 some of us talking in the background to setup an automated QA system to
use existing marvin tests to do long running integration tests but other
than Travis or Jenkins (b.a.o) we don’t have anything.

I hate this but still +1 (CI is/should be there so we don't need this)

--
Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue

[cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A]

M. +91 88 262 30892 | rohit.yadav@shapeblue.com<ma...@shapeblue.com>
Blog: bhaisaab.org<http://bhaisaab.org> | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

Re: [PROPOSAL] stable master and 4.6 release

Posted by Daan Hoogland <da...@gmail.com>.

On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav <ro...@shapeblue.com>
wrote:

> 1. Only BLOCKER fixes to master. If there's something else that needs to
> get in, it can be discussed with the RMs on a case-by-case basis.
>
>
> -1 -ish
> What you’re effectively saying is to freeze/block master from new changes
> until 4.6.0 releases which could take anywhere from one week to many weeks.
> In reality that may be undesirable and can contribute to loss of developer
> productivity time.
>
agree and


>
> Few suggestions, though I’m not sure that best way to go forward: why not
> create a 4.6 branch and merge it back when 4.6.0 releases? Alternatively,
> create a development branch on which development can continue and we merge
> it back to master when that branch is stable enough and 4.6.0 has released?
>
I don't feel we should create a developer branch, branching 4.6.0 now and
fixing blockers there to merge them back to master as they are fixed seems
the way to go to me.



>
> 2. Atleast one of the reviewers of a PR should do the actual tests. We do
> not have good CI in place and travis just does simulator tests.
>
>
> +1 some of us talking in the background to setup an automated QA system to
> use existing marvin tests to do long running integration tests but other
> than Travis or Jenkins (b.a.o) we don’t have anything.
>
I hate this but still +1 (CI is/should be there so we don't need this)



-- 
Daan

Re: [PROPOSAL] stable master and 4.6 release

Posted by Rohit Yadav <ro...@shapeblue.com>.

On 16-Sep-2015, at 11:47 am, Rajani Karuturi <ra...@apache.org>> wrote:

Here is what we propose:

1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.

2. Atleast one of the reviewers of a PR should do the actual tests. We do
not have good CI in place and travis just does simulator tests.

Until we
have a real hypervisor CI in place, manually testing the PR is a must.
Also, LGTM(or +1) should be accompanied with whats tested and why you are
giving LGTM.

+1 at least one person other than the author should have run the PR and tested it manually or otherwise to increase reliance of the patch quality.

Regards,
Rohit Yadav
Software Architect, ShapeBlue

[cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A]

M. +91 88 262 30892 | rohit.yadav@shapeblue.com<ma...@shapeblue.com>
Blog: bhaisaab.org<http://bhaisaab.org> | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services