Re: Next ACS release?
I agree with that, there are regressions occasionally with bugfixes, but I generally don't see any obvious distinction made in the voting thread. Someone finds a problem, they want to patch it, others are found, we roll a new RC. On Wed, Apr 22, 2015 at 3:49 PM, David Nalley wrote: > On Wed, Apr 22, 2015 at 4:47 PM, Marcus wrote: >> We just have to do it. We just freeze master at some point, do all of >> the release bugfixes, and when it is solid enough to pass a release >> vote we branch a release from it, and then only allow merges to master >> that have been tested in a merge branch, or something along those >> lines. Things will slip through, because our testing isn't full >> coverage, but we can begin to add to it. >> >> I've said it before, but I think we're also a bit stingy regarding >> bugfix releases. Unless we cause a regression, there should be no need >> for bugfix releases to go through multiple RCs. We get caught on bugs >> that are already in the shipping version and make them blockers for >> the other bug fixes, or a pet patch needs to slip in (which also only >> matters because bugfix releases are so few and hard to release). >> > > It's not just new features that cause problems though. > We've had bug fixes that cause issues, sometimes worse than the one > they solved. Every change is a threat to stability, so we'd like to > have smaller bug fix releases too. There's an inherent cost in doing > releases in their current form. > > --David
Re: Next ACS release?
h sometimes cool automatic stuff going on!). It'd be >>> interesting to bring that together and share. >>> I think improving this is important, so I'll try to spend as much time on >>> this as possible. >>> >>> However, the tread started with comments on 4.5. Let's try to get it stable >>> and deliver 4.5.1. What is still to be done here? Can we share the load >>> somehow to fasten it? >>> >>> Regards, >>> Remi >>> >>> 2015-04-22 20:13 GMT+02:00 Paul Angus : >>> >>>> I fully support the idea of a stable master with an automated CD process >>>> to protect against regressions. >>>> >>>> However, we obviously don't currently have fantastic integration >>>> testing otherwise we wouldn't have relied on 'people' to pick up the >>>> release blockers recently. A 2 week release cycle IMHO is way too frequent >>>> to expect 'people' to be carrying out integration testing. >>>> >>>> Maybe 1 month is a workable compromise until the integration testing is of >>>> a coverage and standard that can give real confidence. >>>> >>>> >>>> >>>> I'm also going to compile a list of people who vote "+1 - it works on my >>>> laptop" and devise a Guinness related punishment for any of them that show >>>> up at the CloudStack day in Dublin. >>>> >>>> Regards >>>> >>>> Paul Angus >>>> Cloud Architect >>>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus >>>> paul.an...@shapeblue.com >>>> >>>> -Original Message- >>>> From: Remi Bergsma [mailto:r...@remi.nl] >>>> Sent: 22 April 2015 10:25 >>>> To: dev@cloudstack.apache.org >>>> Subject: Re: Next ACS release? >>>> >>>> I'd be happy to help here as well. Last week in Austin, we also discussed >>>> this topic a couple of times. I do agree shorter release cycles are better. >>>> >>>> In my opinion, the first thing to improve is the minor releases in both the >>>> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks >>>> we will be able to do the next minor release with less effort and users can >>>> choose to either wait to start using 4.5 or start now and upgrade when the >>>> next minor release is available. This would have helped in getting 4.5 out >>>> on time and quickly fixing issues after the initial release. Also, it will >>>> save time which we can invest in getting the next release out on time, etc. >>>> >>>> The common thing here is we need more automated testing, preferably >>>> functional testing in addition to unit testing. There might also be other >>>> steps that we do manually now that can be automated. I'll try to understand >>>> the current process first and then come up with a proposal to improve which >>>> we can discuss. >>>> >>>> Regards, >>>> Remi >>>> >>>> 2015-04-22 10:56 GMT+02:00 Erik Weber : >>>> >>>>> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland >>>>> >>>>> wrote: >>>>> >>>>>> On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber >>>>> wrote: >>>>>>> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < >>>>>> stephen.tur...@citrix.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I have to admit I'm a bit sceptical because when we did have a >>>>>> four-month >>>>>>>> release cycle, we never seemed to manage to meet it. Personally I >>>>> think >>>>>>>> six-monthly might be easier. >>>>>>>> >>>>>>>> Having said that, part of the problem was the long close-down >>>>>>>> period >>>>>> where >>>>>>>> we kept finding critical bugs, so more automated testing might >>>>>>>> help to shorten the cycle. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> - Shorter cycle means that it's less of a problem to miss a >>>>>>> deadline, meaning you can spend more time on QA. >>>>>>> - Longer cycle means t
Re: Next ACS release?
@bhinandan and others, note that we have http://jenkins.buildacloud.org/view/parameterized/job/parameterized-slowbuild/ and https://builds.apache.org/view/A-D/view/Cloudstack/job/cloudstack-pull-requests/ those should give people a good idea on whether a branch can be merged to master based on simulator. Of course this is only a first step but let's use them intensively. On Thu, Apr 23, 2015 at 11:56 AM, Ian Southam wrote: > At SBP, we are working on two environments for testing. Primarily focussed > on Xen and KVM with Nicira and without Nicira. > > One will focus more on building and extending the current integration tests > and making sure they are running on real hardware in real life situations. > The other we are planning to be more “chaos monkey” in operation. So > genuinely testing how the system reacts to hypervisors crashing. Loss of > network connectivity, VR failures/failovers and so on. > > I know other people in the community are doing similar things. By having > enough such systems that together have a high coverage of all the various > configuration and hardware combinations out there, we should be able to > really get to a much shorter delivery cycle with quite high levels of > confidence about quality. > > We are not there yet but, I am absolutely convinced that aiming for a 2 week > release cycle is the way to go. > > — > Grts! > Ian > >> On 23 Apr 2015, at 10:38, Abhinandan Prateek >> wrote: >> >> On automated QA front following is available: >> >> 1. Before pushing in a feature a dev can run simulator based tests that will >> basically test various functionality that does not depend on the type of >> Hypervisor. >> (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.) >> The test suite are located in testing/integration/smoke folder. >> The travis system runs most of the test in this folder. >> >> >> 2. Then there are tests that will require real hardware to run most of these >> are in testing/integration/component. >> >> >> Basically there are two kind of test cases not strictly classified as per >> above directory structure - Ones that have required_hardware set as “false” >> and “others” that have this as “true”. >> The one with required_hardware is false can run on simulator but for the >> others you need a real Hypervisor based environment. >> >> I have been able to run a lot of tests both with hardware and simulator. The >> problem I faced is scattered documentation. Missing description of a model >> deployment; say for a particular Hypervisor that will allow a dev to run the >> provisioning tests. >> >> In all there is a huge scope for improvement. >> >> >> -abhi >> >> >>> On 23-Apr-2015, at 1:02 am, Remi Bergsma wrote: >>> >>> Hi, >>> >>> The '2 week cycle' was intended as something to work towards, like a >>> mission. The nice thing is that it immediately shows that we cannot achieve >>> such a thing if we keep our current method of (semi)manual testing, as you >>> said. Totally agree. >>> >>> That's why we need to improve on our automated functional testing. And that >>> will of course take time and effort. As I don't currently have a clear >>> overview of what is already available, I'll try to get that first and work >>> from there. I spoke to several people recently and most seem to do testing >>> on their own way (with sometimes cool automatic stuff going on!). It'd be >>> interesting to bring that together and share. >>> I think improving this is important, so I'll try to spend as much time on >>> this as possible. >>> >>> However, the tread started with comments on 4.5. Let's try to get it stable >>> and deliver 4.5.1. What is still to be done here? Can we share the load >>> somehow to fasten it? >>> >>> Regards, >>> Remi >>> >>> 2015-04-22 20:13 GMT+02:00 Paul Angus : >>> >>>> I fully support the idea of a stable master with an automated CD process >>>> to protect against regressions. >>>> >>>> However, we obviously don't currently have fantastic integration >>>> testing otherwise we wouldn't have relied on 'people' to pick up the >>>> release blockers recently. A 2 week release cycle IMHO is way too frequent >>>> to expect 'people' to be carrying out integration testing. >>>> >>>> Ma
Re: Next ACS release?
At SBP, we are working on two environments for testing. Primarily focussed on Xen and KVM with Nicira and without Nicira. One will focus more on building and extending the current integration tests and making sure they are running on real hardware in real life situations. The other we are planning to be more “chaos monkey” in operation. So genuinely testing how the system reacts to hypervisors crashing. Loss of network connectivity, VR failures/failovers and so on. I know other people in the community are doing similar things. By having enough such systems that together have a high coverage of all the various configuration and hardware combinations out there, we should be able to really get to a much shorter delivery cycle with quite high levels of confidence about quality. We are not there yet but, I am absolutely convinced that aiming for a 2 week release cycle is the way to go. — Grts! Ian > On 23 Apr 2015, at 10:38, Abhinandan Prateek > wrote: > > On automated QA front following is available: > > 1. Before pushing in a feature a dev can run simulator based tests that will > basically test various functionality that does not depend on the type of > Hypervisor. > (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.) > The test suite are located in testing/integration/smoke folder. > The travis system runs most of the test in this folder. > > > 2. Then there are tests that will require real hardware to run most of these > are in testing/integration/component. > > > Basically there are two kind of test cases not strictly classified as per > above directory structure - Ones that have required_hardware set as “false” > and “others” that have this as “true”. > The one with required_hardware is false can run on simulator but for the > others you need a real Hypervisor based environment. > > I have been able to run a lot of tests both with hardware and simulator. The > problem I faced is scattered documentation. Missing description of a model > deployment; say for a particular Hypervisor that will allow a dev to run the > provisioning tests. > > In all there is a huge scope for improvement. > > > -abhi > > >> On 23-Apr-2015, at 1:02 am, Remi Bergsma wrote: >> >> Hi, >> >> The '2 week cycle' was intended as something to work towards, like a >> mission. The nice thing is that it immediately shows that we cannot achieve >> such a thing if we keep our current method of (semi)manual testing, as you >> said. Totally agree. >> >> That's why we need to improve on our automated functional testing. And that >> will of course take time and effort. As I don't currently have a clear >> overview of what is already available, I'll try to get that first and work >> from there. I spoke to several people recently and most seem to do testing >> on their own way (with sometimes cool automatic stuff going on!). It'd be >> interesting to bring that together and share. >> I think improving this is important, so I'll try to spend as much time on >> this as possible. >> >> However, the tread started with comments on 4.5. Let's try to get it stable >> and deliver 4.5.1. What is still to be done here? Can we share the load >> somehow to fasten it? >> >> Regards, >> Remi >> >> 2015-04-22 20:13 GMT+02:00 Paul Angus : >> >>> I fully support the idea of a stable master with an automated CD process >>> to protect against regressions. >>> >>> However, we obviously don't currently have fantastic integration >>> testing otherwise we wouldn't have relied on 'people' to pick up the >>> release blockers recently. A 2 week release cycle IMHO is way too frequent >>> to expect 'people' to be carrying out integration testing. >>> >>> Maybe 1 month is a workable compromise until the integration testing is of >>> a coverage and standard that can give real confidence. >>> >>> >>> >>> I'm also going to compile a list of people who vote "+1 - it works on my >>> laptop" and devise a Guinness related punishment for any of them that show >>> up at the CloudStack day in Dublin. >>> >>> Regards >>> >>> Paul Angus >>> Cloud Architect >>> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus >>> paul.an...@shapeblue.com >>> >>> -Original Message- >>> From: Remi Bergsma [mailto:r...@remi.nl] >>> Sent: 22 April 2015 10:25 >>> To: dev@c
Re: Next ACS release?
On automated QA front following is available: 1. Before pushing in a feature a dev can run simulator based tests that will basically test various functionality that does not depend on the type of Hypervisor. (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator.) The test suite are located in testing/integration/smoke folder. The travis system runs most of the test in this folder. 2. Then there are tests that will require real hardware to run most of these are in testing/integration/component. Basically there are two kind of test cases not strictly classified as per above directory structure - Ones that have required_hardware set as “false” and “others” that have this as “true”. The one with required_hardware is false can run on simulator but for the others you need a real Hypervisor based environment. I have been able to run a lot of tests both with hardware and simulator. The problem I faced is scattered documentation. Missing description of a model deployment; say for a particular Hypervisor that will allow a dev to run the provisioning tests. In all there is a huge scope for improvement. -abhi > On 23-Apr-2015, at 1:02 am, Remi Bergsma wrote: > > Hi, > > The '2 week cycle' was intended as something to work towards, like a > mission. The nice thing is that it immediately shows that we cannot achieve > such a thing if we keep our current method of (semi)manual testing, as you > said. Totally agree. > > That's why we need to improve on our automated functional testing. And that > will of course take time and effort. As I don't currently have a clear > overview of what is already available, I'll try to get that first and work > from there. I spoke to several people recently and most seem to do testing > on their own way (with sometimes cool automatic stuff going on!). It'd be > interesting to bring that together and share. > I think improving this is important, so I'll try to spend as much time on > this as possible. > > However, the tread started with comments on 4.5. Let's try to get it stable > and deliver 4.5.1. What is still to be done here? Can we share the load > somehow to fasten it? > > Regards, > Remi > > 2015-04-22 20:13 GMT+02:00 Paul Angus : > >> I fully support the idea of a stable master with an automated CD process >> to protect against regressions. >> >> However, we obviously don't currently have fantastic integration >> testing otherwise we wouldn't have relied on 'people' to pick up the >> release blockers recently. A 2 week release cycle IMHO is way too frequent >> to expect 'people' to be carrying out integration testing. >> >> Maybe 1 month is a workable compromise until the integration testing is of >> a coverage and standard that can give real confidence. >> >> >> >> I'm also going to compile a list of people who vote "+1 - it works on my >> laptop" and devise a Guinness related punishment for any of them that show >> up at the CloudStack day in Dublin. >> >> Regards >> >> Paul Angus >> Cloud Architect >> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus >> paul.an...@shapeblue.com >> >> -Original Message- >> From: Remi Bergsma [mailto:r...@remi.nl] >> Sent: 22 April 2015 10:25 >> To: dev@cloudstack.apache.org >> Subject: Re: Next ACS release? >> >> I'd be happy to help here as well. Last week in Austin, we also discussed >> this topic a couple of times. I do agree shorter release cycles are better. >> >> In my opinion, the first thing to improve is the minor releases in both the >> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks >> we will be able to do the next minor release with less effort and users can >> choose to either wait to start using 4.5 or start now and upgrade when the >> next minor release is available. This would have helped in getting 4.5 out >> on time and quickly fixing issues after the initial release. Also, it will >> save time which we can invest in getting the next release out on time, etc. >> >> The common thing here is we need more automated testing, preferably >> functional testing in addition to unit testing. There might also be other >> steps that we do manually now that can be automated. I'll try to understand >> the current process first and then come up with a proposal to improve which >> we can discuss. >> >> Regards, >> Remi >> >> 2015-04-22 10:56 GMT+02:00 Erik Weber : >> >>> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland &g
Re: Next ACS release?
Folks, great discussion. I am on vacation, so not ignoring. Will chime in when i return. -Sebastien > On 23 Apr 2015, at 09:57, Daan Hoogland wrote: > > Paul, > This will be interesting: > "I'm also going to compile a list of people who vote "+1 - it works on my > laptop" and devise a Guinness related punishment for any of them that show > up at the CloudStack day in Dublin." > > Why don't you start on list and see how this improves test quality. > > I agree wiith David on the harm bugfixes. can do. The two week cycle is > ment as a moment for initializing a bf rc, not all of them have to make it > or be deemed necessary. > > mobile dev with bilingual spelling checker used (read at your own risk) > Op 23 apr. 2015 00:50 schreef "David Nalley" : > >> On Wed, Apr 22, 2015 at 4:47 PM, Marcus wrote: >>> We just have to do it. We just freeze master at some point, do all of >>> the release bugfixes, and when it is solid enough to pass a release >>> vote we branch a release from it, and then only allow merges to master >>> that have been tested in a merge branch, or something along those >>> lines. Things will slip through, because our testing isn't full >>> coverage, but we can begin to add to it. >>> >>> I've said it before, but I think we're also a bit stingy regarding >>> bugfix releases. Unless we cause a regression, there should be no need >>> for bugfix releases to go through multiple RCs. We get caught on bugs >>> that are already in the shipping version and make them blockers for >>> the other bug fixes, or a pet patch needs to slip in (which also only >>> matters because bugfix releases are so few and hard to release). >>> >> >> It's not just new features that cause problems though. >> We've had bug fixes that cause issues, sometimes worse than the one >> they solved. Every change is a threat to stability, so we'd like to >> have smaller bug fix releases too. There's an inherent cost in doing >> releases in their current form. >> >> --David >>
Re: Next ACS release?
Paul, This will be interesting: "I'm also going to compile a list of people who vote "+1 - it works on my laptop" and devise a Guinness related punishment for any of them that show up at the CloudStack day in Dublin." Why don't you start on list and see how this improves test quality. I agree wiith David on the harm bugfixes. can do. The two week cycle is ment as a moment for initializing a bf rc, not all of them have to make it or be deemed necessary. mobile dev with bilingual spelling checker used (read at your own risk) Op 23 apr. 2015 00:50 schreef "David Nalley" : > On Wed, Apr 22, 2015 at 4:47 PM, Marcus wrote: > > We just have to do it. We just freeze master at some point, do all of > > the release bugfixes, and when it is solid enough to pass a release > > vote we branch a release from it, and then only allow merges to master > > that have been tested in a merge branch, or something along those > > lines. Things will slip through, because our testing isn't full > > coverage, but we can begin to add to it. > > > > I've said it before, but I think we're also a bit stingy regarding > > bugfix releases. Unless we cause a regression, there should be no need > > for bugfix releases to go through multiple RCs. We get caught on bugs > > that are already in the shipping version and make them blockers for > > the other bug fixes, or a pet patch needs to slip in (which also only > > matters because bugfix releases are so few and hard to release). > > > > It's not just new features that cause problems though. > We've had bug fixes that cause issues, sometimes worse than the one > they solved. Every change is a threat to stability, so we'd like to > have smaller bug fix releases too. There's an inherent cost in doing > releases in their current form. > > --David >
Re: Next ACS release?
On Wed, Apr 22, 2015 at 4:47 PM, Marcus wrote: > We just have to do it. We just freeze master at some point, do all of > the release bugfixes, and when it is solid enough to pass a release > vote we branch a release from it, and then only allow merges to master > that have been tested in a merge branch, or something along those > lines. Things will slip through, because our testing isn't full > coverage, but we can begin to add to it. > > I've said it before, but I think we're also a bit stingy regarding > bugfix releases. Unless we cause a regression, there should be no need > for bugfix releases to go through multiple RCs. We get caught on bugs > that are already in the shipping version and make them blockers for > the other bug fixes, or a pet patch needs to slip in (which also only > matters because bugfix releases are so few and hard to release). > It's not just new features that cause problems though. We've had bug fixes that cause issues, sometimes worse than the one they solved. Every change is a threat to stability, so we'd like to have smaller bug fix releases too. There's an inherent cost in doing releases in their current form. --David
Re: Next ACS release?
We just have to do it. We just freeze master at some point, do all of the release bugfixes, and when it is solid enough to pass a release vote we branch a release from it, and then only allow merges to master that have been tested in a merge branch, or something along those lines. Things will slip through, because our testing isn't full coverage, but we can begin to add to it. I've said it before, but I think we're also a bit stingy regarding bugfix releases. Unless we cause a regression, there should be no need for bugfix releases to go through multiple RCs. We get caught on bugs that are already in the shipping version and make them blockers for the other bug fixes, or a pet patch needs to slip in (which also only matters because bugfix releases are so few and hard to release). On Wed, Apr 22, 2015 at 12:32 PM, Remi Bergsma wrote: > Hi, > > The '2 week cycle' was intended as something to work towards, like a > mission. The nice thing is that it immediately shows that we cannot achieve > such a thing if we keep our current method of (semi)manual testing, as you > said. Totally agree. > > That's why we need to improve on our automated functional testing. And that > will of course take time and effort. As I don't currently have a clear > overview of what is already available, I'll try to get that first and work > from there. I spoke to several people recently and most seem to do testing > on their own way (with sometimes cool automatic stuff going on!). It'd be > interesting to bring that together and share. > I think improving this is important, so I'll try to spend as much time on > this as possible. > > However, the tread started with comments on 4.5. Let's try to get it stable > and deliver 4.5.1. What is still to be done here? Can we share the load > somehow to fasten it? > > Regards, > Remi > > 2015-04-22 20:13 GMT+02:00 Paul Angus : > >> I fully support the idea of a stable master with an automated CD process >> to protect against regressions. >> >> However, we obviously don't currently have fantastic integration >> testing otherwise we wouldn't have relied on 'people' to pick up the >> release blockers recently. A 2 week release cycle IMHO is way too frequent >> to expect 'people' to be carrying out integration testing. >> >> Maybe 1 month is a workable compromise until the integration testing is of >> a coverage and standard that can give real confidence. >> >> >> >> I'm also going to compile a list of people who vote "+1 - it works on my >> laptop" and devise a Guinness related punishment for any of them that show >> up at the CloudStack day in Dublin. >> >> Regards >> >> Paul Angus >> Cloud Architect >> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus >> paul.an...@shapeblue.com >> >> -Original Message- >> From: Remi Bergsma [mailto:r...@remi.nl] >> Sent: 22 April 2015 10:25 >> To: dev@cloudstack.apache.org >> Subject: Re: Next ACS release? >> >> I'd be happy to help here as well. Last week in Austin, we also discussed >> this topic a couple of times. I do agree shorter release cycles are better. >> >> In my opinion, the first thing to improve is the minor releases in both the >> 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks >> we will be able to do the next minor release with less effort and users can >> choose to either wait to start using 4.5 or start now and upgrade when the >> next minor release is available. This would have helped in getting 4.5 out >> on time and quickly fixing issues after the initial release. Also, it will >> save time which we can invest in getting the next release out on time, etc. >> >> The common thing here is we need more automated testing, preferably >> functional testing in addition to unit testing. There might also be other >> steps that we do manually now that can be automated. I'll try to understand >> the current process first and then come up with a proposal to improve which >> we can discuss. >> >> Regards, >> Remi >> >> 2015-04-22 10:56 GMT+02:00 Erik Weber : >> >> > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland >> > >> > wrote: >> > >> > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber >> > wrote: >> > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < >> > > stephen.tur...@citrix.com> >> > > > wrote: >> > > > >> > > >> I have to admit I'm a bit sceptical because
Re: AW: Next ACS release?
We need a distributed QA framework, where folks with all kind of setups - fetch code continuously, build cloudstack, run tests, sanitize outputs and submit upstream. Some folks on this list would want to remain anonymous, but this build, deploy, test and submit results process needs to be automated. Would be a great project for GSOC interns. On 4/22/15 2:51 AM, S. Brüseke - proIO GmbH wrote: In my opinion we need to improve QA! If smaller cycles will help to do that this is the way to go. I joined this list after the "release" of 4.5, but as far as I know 4.5 is not really usable for production because of critical bugs in it that good QA would not have passed. So if CS releases new version every 2 month with just a few new features, but these are working, it would be great. We also can do some bug fixing and code-cleaning too. My $.002 Mit freundlichen Grüßen / With kind regards, Swen Brüseke -Ursprüngliche Nachricht- Von: Remi Bergsma [mailto:r...@remi.nl] Gesendet: Mittwoch, 22. April 2015 11:25 An: dev@cloudstack.apache.org Betreff: Re: Next ACS release? I'd be happy to help here as well. Last week in Austin, we also discussed this topic a couple of times. I do agree shorter release cycles are better. In my opinion, the first thing to improve is the minor releases in both the 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we will be able to do the next minor release with less effort and users can choose to either wait to start using 4.5 or start now and upgrade when the next minor release is available. This would have helped in getting 4.5 out on time and quickly fixing issues after the initial release. Also, it will save time which we can invest in getting the next release out on time, etc. The common thing here is we need more automated testing, preferably functional testing in addition to unit testing. There might also be other steps that we do manually now that can be automated. I'll try to understand the current process first and then come up with a proposal to improve which we can discuss. Regards, Remi 2015-04-22 10:56 GMT+02:00 Erik Weber : On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland wrote: On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber wrote: On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < stephen.tur...@citrix.com> wrote: I have to admit I'm a bit sceptical because when we did have a four-month release cycle, we never seemed to manage to meet it. Personally I think six-monthly might be easier. Having said that, part of the problem was the long close-down period where we kept finding critical bugs, so more automated testing might help to shorten the cycle. - Shorter cycle means that it's less of a problem to miss a deadline, meaning you can spend more time on QA. - Longer cycle means that it could be critical to meet the deadline, meaning you might end up doing less QA while stressing to get your feature in. My $.002 Yes, Eric and the amount of qa needed is less as well. Bare with me for a little rant here. When less new features are introduced less new interdependencies are introduced. I could try and expand on this but people make phd on the subject so that would be presumptuous of me. un-educated guess is (m + n)! - m! where m is old features and n is new features example: 1 old feature + 1 new feature mean 1 check to see if they (still) work 1 old feature + 2 new features means 3 checks to see if they all work 2 + 2 = 6 of which only 1 is old and should be fine 2 + 3 = 10, see the n! progressing ;) this is an over simplification as the complexity of features comes in play as well. I make them out for being function points here. those are fables of course. thanks for baring that. I'm all with you on this Daan. Just for the record, my notion of QA was meant at the feature developer, ie. that they could use more time on test coverage etc. without having to worry that much about feature freeze dates. -- Erik - proIO GmbH - Geschäftsführer: Swen Brüseke Sitz der Gesellschaft: Frankfurt am Main USt-IdNr. DE 267 075 918 Registergericht: Frankfurt am Main - HRB 86239 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: Next ACS release?
Hi, The '2 week cycle' was intended as something to work towards, like a mission. The nice thing is that it immediately shows that we cannot achieve such a thing if we keep our current method of (semi)manual testing, as you said. Totally agree. That's why we need to improve on our automated functional testing. And that will of course take time and effort. As I don't currently have a clear overview of what is already available, I'll try to get that first and work from there. I spoke to several people recently and most seem to do testing on their own way (with sometimes cool automatic stuff going on!). It'd be interesting to bring that together and share. I think improving this is important, so I'll try to spend as much time on this as possible. However, the tread started with comments on 4.5. Let's try to get it stable and deliver 4.5.1. What is still to be done here? Can we share the load somehow to fasten it? Regards, Remi 2015-04-22 20:13 GMT+02:00 Paul Angus : > I fully support the idea of a stable master with an automated CD process > to protect against regressions. > > However, we obviously don't currently have fantastic integration > testing otherwise we wouldn't have relied on 'people' to pick up the > release blockers recently. A 2 week release cycle IMHO is way too frequent > to expect 'people' to be carrying out integration testing. > > Maybe 1 month is a workable compromise until the integration testing is of > a coverage and standard that can give real confidence. > > > > I'm also going to compile a list of people who vote "+1 - it works on my > laptop" and devise a Guinness related punishment for any of them that show > up at the CloudStack day in Dublin. > > Regards > > Paul Angus > Cloud Architect > S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus > paul.an...@shapeblue.com > > -Original Message- > From: Remi Bergsma [mailto:r...@remi.nl] > Sent: 22 April 2015 10:25 > To: dev@cloudstack.apache.org > Subject: Re: Next ACS release? > > I'd be happy to help here as well. Last week in Austin, we also discussed > this topic a couple of times. I do agree shorter release cycles are better. > > In my opinion, the first thing to improve is the minor releases in both the > 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks > we will be able to do the next minor release with less effort and users can > choose to either wait to start using 4.5 or start now and upgrade when the > next minor release is available. This would have helped in getting 4.5 out > on time and quickly fixing issues after the initial release. Also, it will > save time which we can invest in getting the next release out on time, etc. > > The common thing here is we need more automated testing, preferably > functional testing in addition to unit testing. There might also be other > steps that we do manually now that can be automated. I'll try to understand > the current process first and then come up with a proposal to improve which > we can discuss. > > Regards, > Remi > > 2015-04-22 10:56 GMT+02:00 Erik Weber : > > > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland > > > > wrote: > > > > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber > > wrote: > > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < > > > stephen.tur...@citrix.com> > > > > wrote: > > > > > > > >> I have to admit I'm a bit sceptical because when we did have a > > > four-month > > > >> release cycle, we never seemed to manage to meet it. Personally I > > think > > > >> six-monthly might be easier. > > > >> > > > >> Having said that, part of the problem was the long close-down > > > >> period > > > where > > > >> we kept finding critical bugs, so more automated testing might > > > >> help to shorten the cycle. > > > >> > > > >> > > > > > > > > - Shorter cycle means that it's less of a problem to miss a > > > > deadline, meaning you can spend more time on QA. > > > > - Longer cycle means that it could be critical to meet the > > > > deadline, meaning you might end up doing less QA while stressing > > > > to get your > > > feature > > > > in. > > > > > > > > My $.002 > > > > > > > > Yes, Eric and the amount of qa needed is less as well. Bare with me > > > for a little rant here. > > > > > > When less new features are introduced l
Re: Next ACS release?
+1 what Paul said. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Paul Angus" > To: dev@cloudstack.apache.org > Sent: Wednesday, 22 April, 2015 19:13:04 > Subject: RE: Next ACS release? > I fully support the idea of a stable master with an automated CD process to > protect against regressions. > > However, we obviously don't currently have fantastic integration testing > otherwise we wouldn't have relied on 'people' to pick up the release blockers > recently. A 2 week release cycle IMHO is way too frequent to expect 'people' > to be carrying out integration testing. > > Maybe 1 month is a workable compromise until the integration testing is of a > coverage and standard that can give real confidence. > > > > I'm also going to compile a list of people who vote "+1 - it works on my > laptop" > and devise a Guinness related punishment for any of them that show up at the > CloudStack day in Dublin. > > Regards > > Paul Angus > Cloud Architect > S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus > paul.an...@shapeblue.com > > -Original Message- > From: Remi Bergsma [mailto:r...@remi.nl] > Sent: 22 April 2015 10:25 > To: dev@cloudstack.apache.org > Subject: Re: Next ACS release? > > I'd be happy to help here as well. Last week in Austin, we also discussed this > topic a couple of times. I do agree shorter release cycles are better. > > In my opinion, the first thing to improve is the minor releases in both the > 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we > will be able to do the next minor release with less effort and users can > choose > to either wait to start using 4.5 or start now and upgrade when the next minor > release is available. This would have helped in getting 4.5 out on time and > quickly fixing issues after the initial release. Also, it will save time which > we can invest in getting the next release out on time, etc. > > The common thing here is we need more automated testing, preferably functional > testing in addition to unit testing. There might also be other steps that we > do > manually now that can be automated. I'll try to understand the current process > first and then come up with a proposal to improve which we can discuss. > > Regards, > Remi > > 2015-04-22 10:56 GMT+02:00 Erik Weber : > >> On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland >> >> wrote: >> >> > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber >> wrote: >> > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < >> > stephen.tur...@citrix.com> >> > > wrote: >> > > >> > >> I have to admit I'm a bit sceptical because when we did have a >> > four-month >> > >> release cycle, we never seemed to manage to meet it. Personally I >> think >> > >> six-monthly might be easier. >> > >> >> > >> Having said that, part of the problem was the long close-down >> > >> period >> > where >> > >> we kept finding critical bugs, so more automated testing might >> > >> help to shorten the cycle. >> > >> >> > >> >> > > >> > > - Shorter cycle means that it's less of a problem to miss a >> > > deadline, meaning you can spend more time on QA. >> > > - Longer cycle means that it could be critical to meet the >> > > deadline, meaning you might end up doing less QA while stressing >> > > to get your >> > feature >> > > in. >> > > >> > > My $.002 >> > >> > >> Yes, Eric and the amount of qa needed is less as well. Bare with me >> > for a little rant here. >> > >> > When less new features are introduced less new interdependencies are >> > introduced. I could try and expand on this but people make phd on >> > the subject so that would be presumptuous of me. >> > >> > un-educated guess is (m + n)! - m! >> > where m is old features and n is new features >> > >> > example: >> > 1 old feature + 1 new feature mean 1 check to see if they (still) >> > work >> > 1 old feature + 2 new features means 3 checks to see if they all >> > work >> > 2 + 2 = 6 of which only 1 is old and should be fine >> > 2 + 3 = 10, see the n! progressing ;) >> > >> > >> > this is an over simplification as the complexity of features comes >
RE: Next ACS release?
I fully support the idea of a stable master with an automated CD process to protect against regressions. However, we obviously don't currently have fantastic integration testing otherwise we wouldn't have relied on 'people' to pick up the release blockers recently. A 2 week release cycle IMHO is way too frequent to expect 'people' to be carrying out integration testing. Maybe 1 month is a workable compromise until the integration testing is of a coverage and standard that can give real confidence. I'm also going to compile a list of people who vote "+1 - it works on my laptop" and devise a Guinness related punishment for any of them that show up at the CloudStack day in Dublin. Regards Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus paul.an...@shapeblue.com -Original Message- From: Remi Bergsma [mailto:r...@remi.nl] Sent: 22 April 2015 10:25 To: dev@cloudstack.apache.org Subject: Re: Next ACS release? I'd be happy to help here as well. Last week in Austin, we also discussed this topic a couple of times. I do agree shorter release cycles are better. In my opinion, the first thing to improve is the minor releases in both the 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we will be able to do the next minor release with less effort and users can choose to either wait to start using 4.5 or start now and upgrade when the next minor release is available. This would have helped in getting 4.5 out on time and quickly fixing issues after the initial release. Also, it will save time which we can invest in getting the next release out on time, etc. The common thing here is we need more automated testing, preferably functional testing in addition to unit testing. There might also be other steps that we do manually now that can be automated. I'll try to understand the current process first and then come up with a proposal to improve which we can discuss. Regards, Remi 2015-04-22 10:56 GMT+02:00 Erik Weber : > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland > > wrote: > > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber > wrote: > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < > > stephen.tur...@citrix.com> > > > wrote: > > > > > >> I have to admit I'm a bit sceptical because when we did have a > > four-month > > >> release cycle, we never seemed to manage to meet it. Personally I > think > > >> six-monthly might be easier. > > >> > > >> Having said that, part of the problem was the long close-down > > >> period > > where > > >> we kept finding critical bugs, so more automated testing might > > >> help to shorten the cycle. > > >> > > >> > > > > > > - Shorter cycle means that it's less of a problem to miss a > > > deadline, meaning you can spend more time on QA. > > > - Longer cycle means that it could be critical to meet the > > > deadline, meaning you might end up doing less QA while stressing > > > to get your > > feature > > > in. > > > > > > My $.002 > > > > > Yes, Eric and the amount of qa needed is less as well. Bare with me > > for a little rant here. > > > > When less new features are introduced less new interdependencies are > > introduced. I could try and expand on this but people make phd on > > the subject so that would be presumptuous of me. > > > > un-educated guess is (m + n)! - m! > > where m is old features and n is new features > > > > example: > > 1 old feature + 1 new feature mean 1 check to see if they (still) > > work > > 1 old feature + 2 new features means 3 checks to see if they all > > work > > 2 + 2 = 6 of which only 1 is old and should be fine > > 2 + 3 = 10, see the n! progressing ;) > > > > > > this is an over simplification as the complexity of features comes > > in play as well. I make them out for being function points here. > > those are fables of course. > > > > thanks for baring that. > > > > > I'm all with you on this Daan. > Just for the record, my notion of QA was meant at the feature > developer, ie. that they could use more time on test coverage etc. > without having to worry that much about feature freeze dates. > > -- > Erik > 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-consu
AW: Next ACS release?
In my opinion we need to improve QA! If smaller cycles will help to do that this is the way to go. I joined this list after the "release" of 4.5, but as far as I know 4.5 is not really usable for production because of critical bugs in it that good QA would not have passed. So if CS releases new version every 2 month with just a few new features, but these are working, it would be great. We also can do some bug fixing and code-cleaning too. My $.002 Mit freundlichen Grüßen / With kind regards, Swen Brüseke -Ursprüngliche Nachricht- Von: Remi Bergsma [mailto:r...@remi.nl] Gesendet: Mittwoch, 22. April 2015 11:25 An: dev@cloudstack.apache.org Betreff: Re: Next ACS release? I'd be happy to help here as well. Last week in Austin, we also discussed this topic a couple of times. I do agree shorter release cycles are better. In my opinion, the first thing to improve is the minor releases in both the 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we will be able to do the next minor release with less effort and users can choose to either wait to start using 4.5 or start now and upgrade when the next minor release is available. This would have helped in getting 4.5 out on time and quickly fixing issues after the initial release. Also, it will save time which we can invest in getting the next release out on time, etc. The common thing here is we need more automated testing, preferably functional testing in addition to unit testing. There might also be other steps that we do manually now that can be automated. I'll try to understand the current process first and then come up with a proposal to improve which we can discuss. Regards, Remi 2015-04-22 10:56 GMT+02:00 Erik Weber : > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland > > wrote: > > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber > wrote: > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < > > stephen.tur...@citrix.com> > > > wrote: > > > > > >> I have to admit I'm a bit sceptical because when we did have a > > four-month > > >> release cycle, we never seemed to manage to meet it. Personally I > think > > >> six-monthly might be easier. > > >> > > >> Having said that, part of the problem was the long close-down > > >> period > > where > > >> we kept finding critical bugs, so more automated testing might > > >> help to shorten the cycle. > > >> > > >> > > > > > > - Shorter cycle means that it's less of a problem to miss a > > > deadline, meaning you can spend more time on QA. > > > - Longer cycle means that it could be critical to meet the > > > deadline, meaning you might end up doing less QA while stressing > > > to get your > > feature > > > in. > > > > > > My $.002 > > > > > Yes, Eric and the amount of qa needed is less as well. Bare with me > > for a little rant here. > > > > When less new features are introduced less new interdependencies are > > introduced. I could try and expand on this but people make phd on > > the subject so that would be presumptuous of me. > > > > un-educated guess is (m + n)! - m! > > where m is old features and n is new features > > > > example: > > 1 old feature + 1 new feature mean 1 check to see if they (still) > > work > > 1 old feature + 2 new features means 3 checks to see if they all > > work > > 2 + 2 = 6 of which only 1 is old and should be fine > > 2 + 3 = 10, see the n! progressing ;) > > > > > > this is an over simplification as the complexity of features comes > > in play as well. I make them out for being function points here. > > those are fables of course. > > > > thanks for baring that. > > > > > I'm all with you on this Daan. > Just for the record, my notion of QA was meant at the feature > developer, ie. that they could use more time on test coverage etc. > without having to worry that much about feature freeze dates. > > -- > Erik > - proIO GmbH - Geschäftsführer: Swen Brüseke Sitz der Gesellschaft: Frankfurt am Main USt-IdNr. DE 267 075 918 Registergericht: Frankfurt am Main - HRB 86239 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: Next ACS release?
I'd be happy to help here as well. Last week in Austin, we also discussed this topic a couple of times. I do agree shorter release cycles are better. In my opinion, the first thing to improve is the minor releases in both the 4.4 and 4.5 branches. If we speed those up to let's say once every 2-weeks we will be able to do the next minor release with less effort and users can choose to either wait to start using 4.5 or start now and upgrade when the next minor release is available. This would have helped in getting 4.5 out on time and quickly fixing issues after the initial release. Also, it will save time which we can invest in getting the next release out on time, etc. The common thing here is we need more automated testing, preferably functional testing in addition to unit testing. There might also be other steps that we do manually now that can be automated. I'll try to understand the current process first and then come up with a proposal to improve which we can discuss. Regards, Remi 2015-04-22 10:56 GMT+02:00 Erik Weber : > On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland > wrote: > > > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber > wrote: > > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < > > stephen.tur...@citrix.com> > > > wrote: > > > > > >> I have to admit I'm a bit sceptical because when we did have a > > four-month > > >> release cycle, we never seemed to manage to meet it. Personally I > think > > >> six-monthly might be easier. > > >> > > >> Having said that, part of the problem was the long close-down period > > where > > >> we kept finding critical bugs, so more automated testing might help to > > >> shorten the cycle. > > >> > > >> > > > > > > - Shorter cycle means that it's less of a problem to miss a deadline, > > > meaning you can spend more time on QA. > > > - Longer cycle means that it could be critical to meet the deadline, > > > meaning you might end up doing less QA while stressing to get your > > feature > > > in. > > > > > > My $.002 > > > > > Yes, Eric and the amount of qa needed is less as well. Bare with me > > for a little rant here. > > > > When less new features are introduced less new interdependencies are > > introduced. I could try and expand on this but people make phd on the > > subject so that would be presumptuous of me. > > > > un-educated guess is (m + n)! - m! > > where m is old features and n is new features > > > > example: > > 1 old feature + 1 new feature mean 1 check to see if they (still) work > > 1 old feature + 2 new features means 3 checks to see if they all work > > 2 + 2 = 6 of which only 1 is old and should be fine > > 2 + 3 = 10, see the n! progressing ;) > > > > > > this is an over simplification as the complexity of features comes in > > play as well. I make them out for being function points here. those > > are fables of course. > > > > thanks for baring that. > > > > > I'm all with you on this Daan. > Just for the record, my notion of QA was meant at the feature developer, > ie. that they could use more time on test coverage etc. without having to > worry that much about feature freeze dates. > > -- > Erik >
Re: Next ACS release?
On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland wrote: > On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber wrote: > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < > stephen.tur...@citrix.com> > > wrote: > > > >> I have to admit I'm a bit sceptical because when we did have a > four-month > >> release cycle, we never seemed to manage to meet it. Personally I think > >> six-monthly might be easier. > >> > >> Having said that, part of the problem was the long close-down period > where > >> we kept finding critical bugs, so more automated testing might help to > >> shorten the cycle. > >> > >> > > > > - Shorter cycle means that it's less of a problem to miss a deadline, > > meaning you can spend more time on QA. > > - Longer cycle means that it could be critical to meet the deadline, > > meaning you might end up doing less QA while stressing to get your > feature > > in. > > > > My $.002 > > Yes, Eric and the amount of qa needed is less as well. Bare with me > for a little rant here. > > When less new features are introduced less new interdependencies are > introduced. I could try and expand on this but people make phd on the > subject so that would be presumptuous of me. > > un-educated guess is (m + n)! - m! > where m is old features and n is new features > > example: > 1 old feature + 1 new feature mean 1 check to see if they (still) work > 1 old feature + 2 new features means 3 checks to see if they all work > 2 + 2 = 6 of which only 1 is old and should be fine > 2 + 3 = 10, see the n! progressing ;) > > > this is an over simplification as the complexity of features comes in > play as well. I make them out for being function points here. those > are fables of course. > > thanks for baring that. > > I'm all with you on this Daan. Just for the record, my notion of QA was meant at the feature developer, ie. that they could use more time on test coverage etc. without having to worry that much about feature freeze dates. -- Erik
Re: Next ACS release?
for us all to agree we should go this way. then for us to have a (scheduled?) volunteer. On Wed, Apr 22, 2015 at 10:44 AM, Nux! wrote: > What is required for this RM to happen? > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > - Original Message - >> From: "Daan Hoogland" >> To: "dev" >> Sent: Wednesday, 22 April, 2015 09:28:27 >> Subject: Re: Next ACS release? > >> the community is us... (well not just us, Wido) Having a master RM >> would be my first step towards this goal. >> >> On Wed, Apr 22, 2015 at 10:18 AM, Wido den Hollander wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> >>> >>> On 04/22/2015 10:08 AM, Daan Hoogland wrote: >>>> I strongly advice my fellow community members to go for a lower >>>> duration, not longer. Each feature deserves a release and I'd say >>>> let's release every 2 months, provides a new feature was added. >>>> Also we now release fix releases when we feel the urgency. This >>>> means users, that are not also developers have little influence. >>>> Let's release every two weeks, provided fixes where applicable. >>>> >>>> €0,02++ wanting to get out of this vicious circle is my drive >>>> >>> >>> Oh, I would really love that to happen. No doubt about it :-) >>> >>>> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner >>>> wrote: >>>>> I have to admit I'm a bit sceptical because when we did have a >>>>> four-month release cycle, we never seemed to manage to meet it. >>>>> Personally I think six-monthly might be easier. >>>>> >>>>> Having said that, part of the problem was the long close-down >>>>> period where we kept finding critical bugs, so more automated >>>>> testing might help to shorten the cycle. >>>>> >>>>> -- Stephen Turner >>>>> >>>>> >>>>> >>>>> >>>>> -Original Message- From: Andrei Mikhailovsky >>>>> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To: >>>>> dev@cloudstack.apache.org Subject: Re: Next ACS release? >>>>> >>>>> Ilya, Mark, thanks for your feedback, >>>>> >>>>> I also see the need to restructure the release schedule for ACS >>>>> as the current release cycles are not really working. There is no >>>>> _reliable_ release cycle of the product and as we have recently >>>>> seen with the 4.5 branch, the release did not happen for months >>>>> and it is still not clear when this will take place. In my (I >>>>> must admit somewhat limited) experience if there are no >>>>> deadlines, developers are not keen on releases and the release >>>>> are likely to be delayed. This is what we've seen with the past >>>>> ACS releases, they are overdue by many months. >>>>> >>>>> The community might get a much better responce if there is a much >>>>> shorter release cycle even if it means pushing out less features >>>>> with each release. At least some features will get completed, >>>>> tested and implemented in a set time frame. I would rather see a >>>>> release cycle of every 3-4 months with 5 new features than a >>>>> release with 15 new features which may or may not get released >>>>> every 9 - 12 months. >>>>> >>>>> By any means, please comment if someone disagrees or thinks there >>>>> is a better alternative. >>>>> >>>>> Andrei - Original Message - >>>>> >>>>>> From: "ilya" To: >>>>>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34 >>>>>> PM Subject: Re: Next ACS release? >>>>> >>>>>> Andrei, >>>>> >>>>>> To best of my knowledge, both 4.4.x and 4.5.x are being worked >>>>>> on actively. As a community, we need to get better on QA of >>>>>> each release - this is something we are planning to cover this >>>>>> year with distributed QA model, this was not widely discussed >>>>>> yet but something we need to tackle. >>>>> >>>>>> 4.5 rc2 got stalled and we need to restart. We had a
Re: Next ACS release?
Yes, Eric and the amount of qa needed is less as well. Bare with me for a little rant here. When less new features are introduced less new interdependencies are introduced. I could try and expand on this but people make phd on the subject so that would be presumptuous of me. un-educated guess is (m + n)! - m! where m is old features and n is new features example: 1 old feature + 1 new feature mean 1 check to see if they (still) work 1 old feature + 2 new features means 3 checks to see if they all work 2 + 2 = 6 of which only 1 is old and should be fine 2 + 3 = 10, see the n! progressing ;) this is an over simplification as the complexity of features comes in play as well. I make them out for being function points here. those are fables of course. thanks for baring that. On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber wrote: > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner > wrote: > >> I have to admit I'm a bit sceptical because when we did have a four-month >> release cycle, we never seemed to manage to meet it. Personally I think >> six-monthly might be easier. >> >> Having said that, part of the problem was the long close-down period where >> we kept finding critical bugs, so more automated testing might help to >> shorten the cycle. >> >> > > - Shorter cycle means that it's less of a problem to miss a deadline, > meaning you can spend more time on QA. > - Longer cycle means that it could be critical to meet the deadline, > meaning you might end up doing less QA while stressing to get your feature > in. > > My $.002 > > -- > Erik -- Daan
Re: Next ACS release?
What is required for this RM to happen? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Daan Hoogland" > To: "dev" > Sent: Wednesday, 22 April, 2015 09:28:27 > Subject: Re: Next ACS release? > the community is us... (well not just us, Wido) Having a master RM > would be my first step towards this goal. > > On Wed, Apr 22, 2015 at 10:18 AM, Wido den Hollander wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> >> >> On 04/22/2015 10:08 AM, Daan Hoogland wrote: >>> I strongly advice my fellow community members to go for a lower >>> duration, not longer. Each feature deserves a release and I'd say >>> let's release every 2 months, provides a new feature was added. >>> Also we now release fix releases when we feel the urgency. This >>> means users, that are not also developers have little influence. >>> Let's release every two weeks, provided fixes where applicable. >>> >>> €0,02++ wanting to get out of this vicious circle is my drive >>> >> >> Oh, I would really love that to happen. No doubt about it :-) >> >>> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner >>> wrote: >>>> I have to admit I'm a bit sceptical because when we did have a >>>> four-month release cycle, we never seemed to manage to meet it. >>>> Personally I think six-monthly might be easier. >>>> >>>> Having said that, part of the problem was the long close-down >>>> period where we kept finding critical bugs, so more automated >>>> testing might help to shorten the cycle. >>>> >>>> -- Stephen Turner >>>> >>>> >>>> >>>> >>>> -Original Message- From: Andrei Mikhailovsky >>>> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To: >>>> dev@cloudstack.apache.org Subject: Re: Next ACS release? >>>> >>>> Ilya, Mark, thanks for your feedback, >>>> >>>> I also see the need to restructure the release schedule for ACS >>>> as the current release cycles are not really working. There is no >>>> _reliable_ release cycle of the product and as we have recently >>>> seen with the 4.5 branch, the release did not happen for months >>>> and it is still not clear when this will take place. In my (I >>>> must admit somewhat limited) experience if there are no >>>> deadlines, developers are not keen on releases and the release >>>> are likely to be delayed. This is what we've seen with the past >>>> ACS releases, they are overdue by many months. >>>> >>>> The community might get a much better responce if there is a much >>>> shorter release cycle even if it means pushing out less features >>>> with each release. At least some features will get completed, >>>> tested and implemented in a set time frame. I would rather see a >>>> release cycle of every 3-4 months with 5 new features than a >>>> release with 15 new features which may or may not get released >>>> every 9 - 12 months. >>>> >>>> By any means, please comment if someone disagrees or thinks there >>>> is a better alternative. >>>> >>>> Andrei - Original Message - >>>> >>>>> From: "ilya" To: >>>>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34 >>>>> PM Subject: Re: Next ACS release? >>>> >>>>> Andrei, >>>> >>>>> To best of my knowledge, both 4.4.x and 4.5.x are being worked >>>>> on actively. As a community, we need to get better on QA of >>>>> each release - this is something we are planning to cover this >>>>> year with distributed QA model, this was not widely discussed >>>>> yet but something we need to tackle. >>>> >>>>> 4.5 rc2 got stalled and we need to restart. We had a 4 month >>>>> release cycle, but we can really stick to it hard - as its >>>>> community driven. May will have to revise it down to 6 months >>>>> or so. >>>> >>>>> Regards ilya >>>> >>>>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: >>>>>> Hello guys, >>>>>> >>>>>> Looking at the dev and user lists it is becoming less certain >>>>>> if vers
Re: Next ACS release?
On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner wrote: > I have to admit I'm a bit sceptical because when we did have a four-month > release cycle, we never seemed to manage to meet it. Personally I think > six-monthly might be easier. > > Having said that, part of the problem was the long close-down period where > we kept finding critical bugs, so more automated testing might help to > shorten the cycle. > > - Shorter cycle means that it's less of a problem to miss a deadline, meaning you can spend more time on QA. - Longer cycle means that it could be critical to meet the deadline, meaning you might end up doing less QA while stressing to get your feature in. My $.002 -- Erik
Re: Next ACS release?
the community is us... (well not just us, Wido) Having a master RM would be my first step towards this goal. On Wed, Apr 22, 2015 at 10:18 AM, Wido den Hollander wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 04/22/2015 10:08 AM, Daan Hoogland wrote: >> I strongly advice my fellow community members to go for a lower >> duration, not longer. Each feature deserves a release and I'd say >> let's release every 2 months, provides a new feature was added. >> Also we now release fix releases when we feel the urgency. This >> means users, that are not also developers have little influence. >> Let's release every two weeks, provided fixes where applicable. >> >> €0,02++ wanting to get out of this vicious circle is my drive >> > > Oh, I would really love that to happen. No doubt about it :-) > >> On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner >> wrote: >>> I have to admit I'm a bit sceptical because when we did have a >>> four-month release cycle, we never seemed to manage to meet it. >>> Personally I think six-monthly might be easier. >>> >>> Having said that, part of the problem was the long close-down >>> period where we kept finding critical bugs, so more automated >>> testing might help to shorten the cycle. >>> >>> -- Stephen Turner >>> >>> >>> >>> >>> -Original Message- From: Andrei Mikhailovsky >>> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To: >>> dev@cloudstack.apache.org Subject: Re: Next ACS release? >>> >>> Ilya, Mark, thanks for your feedback, >>> >>> I also see the need to restructure the release schedule for ACS >>> as the current release cycles are not really working. There is no >>> _reliable_ release cycle of the product and as we have recently >>> seen with the 4.5 branch, the release did not happen for months >>> and it is still not clear when this will take place. In my (I >>> must admit somewhat limited) experience if there are no >>> deadlines, developers are not keen on releases and the release >>> are likely to be delayed. This is what we've seen with the past >>> ACS releases, they are overdue by many months. >>> >>> The community might get a much better responce if there is a much >>> shorter release cycle even if it means pushing out less features >>> with each release. At least some features will get completed, >>> tested and implemented in a set time frame. I would rather see a >>> release cycle of every 3-4 months with 5 new features than a >>> release with 15 new features which may or may not get released >>> every 9 - 12 months. >>> >>> By any means, please comment if someone disagrees or thinks there >>> is a better alternative. >>> >>> Andrei - Original Message - >>> >>>> From: "ilya" To: >>>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34 >>>> PM Subject: Re: Next ACS release? >>> >>>> Andrei, >>> >>>> To best of my knowledge, both 4.4.x and 4.5.x are being worked >>>> on actively. As a community, we need to get better on QA of >>>> each release - this is something we are planning to cover this >>>> year with distributed QA model, this was not widely discussed >>>> yet but something we need to tackle. >>> >>>> 4.5 rc2 got stalled and we need to restart. We had a 4 month >>>> release cycle, but we can really stick to it hard - as its >>>> community driven. May will have to revise it down to 6 months >>>> or so. >>> >>>> Regards ilya >>> >>>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: >>>>> Hello guys, >>>>> >>>>> Looking at the dev and user lists it is becoming less certain >>>>> if version 4.5.x is ever coming out. It seems like a few >>>>> months have passed since the not so fortunate release of >>>>> 4.5.0 and I can't find a release schedule for the 4.5.1, >>>>> which seems to have stopped at rc2 stage and haven't >>>>> progressed further to a release stage. >>>>> >>>>> Are we likely to see any progress with the 4.5.x branch or is >>>>> the community switching towards the 4.6.x branch without >>>>> releasing the 4.5.x? >>>>> >>>>> I am a bit unclea
Re: Next ACS release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2015 10:08 AM, Daan Hoogland wrote: > I strongly advice my fellow community members to go for a lower > duration, not longer. Each feature deserves a release and I'd say > let's release every 2 months, provides a new feature was added. > Also we now release fix releases when we feel the urgency. This > means users, that are not also developers have little influence. > Let's release every two weeks, provided fixes where applicable. > > €0,02++ wanting to get out of this vicious circle is my drive > Oh, I would really love that to happen. No doubt about it :-) > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner > wrote: >> I have to admit I'm a bit sceptical because when we did have a >> four-month release cycle, we never seemed to manage to meet it. >> Personally I think six-monthly might be easier. >> >> Having said that, part of the problem was the long close-down >> period where we kept finding critical bugs, so more automated >> testing might help to shorten the cycle. >> >> -- Stephen Turner >> >> >> >> >> -Original Message- From: Andrei Mikhailovsky >> [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To: >> dev@cloudstack.apache.org Subject: Re: Next ACS release? >> >> Ilya, Mark, thanks for your feedback, >> >> I also see the need to restructure the release schedule for ACS >> as the current release cycles are not really working. There is no >> _reliable_ release cycle of the product and as we have recently >> seen with the 4.5 branch, the release did not happen for months >> and it is still not clear when this will take place. In my (I >> must admit somewhat limited) experience if there are no >> deadlines, developers are not keen on releases and the release >> are likely to be delayed. This is what we've seen with the past >> ACS releases, they are overdue by many months. >> >> The community might get a much better responce if there is a much >> shorter release cycle even if it means pushing out less features >> with each release. At least some features will get completed, >> tested and implemented in a set time frame. I would rather see a >> release cycle of every 3-4 months with 5 new features than a >> release with 15 new features which may or may not get released >> every 9 - 12 months. >> >> By any means, please comment if someone disagrees or thinks there >> is a better alternative. >> >> Andrei - Original Message - >> >>> From: "ilya" To: >>> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34 >>> PM Subject: Re: Next ACS release? >> >>> Andrei, >> >>> To best of my knowledge, both 4.4.x and 4.5.x are being worked >>> on actively. As a community, we need to get better on QA of >>> each release - this is something we are planning to cover this >>> year with distributed QA model, this was not widely discussed >>> yet but something we need to tackle. >> >>> 4.5 rc2 got stalled and we need to restart. We had a 4 month >>> release cycle, but we can really stick to it hard - as its >>> community driven. May will have to revise it down to 6 months >>> or so. >> >>> Regards ilya >> >>> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: >>>> Hello guys, >>>> >>>> Looking at the dev and user lists it is becoming less certain >>>> if version 4.5.x is ever coming out. It seems like a few >>>> months have passed since the not so fortunate release of >>>> 4.5.0 and I can't find a release schedule for the 4.5.1, >>>> which seems to have stopped at rc2 stage and haven't >>>> progressed further to a release stage. >>>> >>>> Are we likely to see any progress with the 4.5.x branch or is >>>> the community switching towards the 4.6.x branch without >>>> releasing the 4.5.x? >>>> >>>> I am a bit unclear as there are no release dates, schedules >>>> or dead lines that the community should work with. Possibly >>>> as a result of this, the ACS releases are not being released >>>> on time or fast enough. >>>> >>>> Does it make sense to introduce release schedules for ACS >>>> that the dev community should stick to? Similar to what is >>>> being done in many other projects, like Ubuntu, etc. Or would >>>> this break the ACS pro
Re: Next ACS release?
I strongly advice my fellow community members to go for a lower duration, not longer. Each feature deserves a release and I'd say let's release every 2 months, provides a new feature was added. Also we now release fix releases when we feel the urgency. This means users, that are not also developers have little influence. Let's release every two weeks, provided fixes where applicable. €0,02++ wanting to get out of this vicious circle is my drive On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner wrote: > I have to admit I'm a bit sceptical because when we did have a four-month > release cycle, we never seemed to manage to meet it. Personally I think > six-monthly might be easier. > > Having said that, part of the problem was the long close-down period where we > kept finding critical bugs, so more automated testing might help to shorten > the cycle. > > -- > Stephen Turner > > > > > -Original Message- > From: Andrei Mikhailovsky [mailto:and...@arhont.com] > Sent: 21 April 2015 11:39 PM > To: dev@cloudstack.apache.org > Subject: Re: Next ACS release? > > Ilya, Mark, thanks for your feedback, > > I also see the need to restructure the release schedule for ACS as the > current release cycles are not really working. There is no _reliable_ release > cycle of the product and as we have recently seen with the 4.5 branch, the > release did not happen for months and it is still not clear when this will > take place. In my (I must admit somewhat limited) experience if there are no > deadlines, developers are not keen on releases and the release are likely to > be delayed. This is what we've seen with the past ACS releases, they are > overdue by many months. > > The community might get a much better responce if there is a much shorter > release cycle even if it means pushing out less features with each release. > At least some features will get completed, tested and implemented in a set > time frame. I would rather see a release cycle of every 3-4 months with 5 new > features than a release with 15 new features which may or may not get > released every 9 - 12 months. > > By any means, please comment if someone disagrees or thinks there is a better > alternative. > > Andrei > ----- Original Message - > >> From: "ilya" >> To: dev@cloudstack.apache.org >> Sent: Tuesday, 21 April, 2015 7:30:34 PM >> Subject: Re: Next ACS release? > >> Andrei, > >> To best of my knowledge, both 4.4.x and 4.5.x are being worked on >> actively. As a community, we need to get better on QA of each release >> - >> this is something we are planning to cover this year with distributed >> QA model, this was not widely discussed yet but something we need to >> tackle. > >> 4.5 rc2 got stalled and we need to restart. We had a 4 month release >> cycle, but we can really stick to it hard - as its community driven. >> May >> will have to revise it down to 6 months or so. > >> Regards >> ilya > >> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: >> > Hello guys, >> > >> > Looking at the dev and user lists it is becoming less certain if >> > version 4.5.x is ever coming out. It seems like a few months have >> > passed since the not so fortunate release of 4.5.0 and I can't find >> > a release schedule for the 4.5.1, which seems to have stopped at rc2 >> > stage and haven't progressed further to a release stage. >> > >> > Are we likely to see any progress with the 4.5.x branch or is the >> > community switching towards the 4.6.x branch without releasing the >> > 4.5.x? >> > >> > I am a bit unclear as there are no release dates, schedules or dead >> > lines that the community should work with. Possibly as a result of >> > this, the ACS releases are not being released on time or fast >> > enough. >> > >> > Does it make sense to introduce release schedules for ACS that the >> > dev community should stick to? Similar to what is being done in many >> > other projects, like Ubuntu, etc. Or would this break the ACS >> > project releases even more? >> > >> > Andrei >> > -- Daan
RE: Next ACS release?
I have to admit I'm a bit sceptical because when we did have a four-month release cycle, we never seemed to manage to meet it. Personally I think six-monthly might be easier. Having said that, part of the problem was the long close-down period where we kept finding critical bugs, so more automated testing might help to shorten the cycle. -- Stephen Turner -Original Message- From: Andrei Mikhailovsky [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To: dev@cloudstack.apache.org Subject: Re: Next ACS release? Ilya, Mark, thanks for your feedback, I also see the need to restructure the release schedule for ACS as the current release cycles are not really working. There is no _reliable_ release cycle of the product and as we have recently seen with the 4.5 branch, the release did not happen for months and it is still not clear when this will take place. In my (I must admit somewhat limited) experience if there are no deadlines, developers are not keen on releases and the release are likely to be delayed. This is what we've seen with the past ACS releases, they are overdue by many months. The community might get a much better responce if there is a much shorter release cycle even if it means pushing out less features with each release. At least some features will get completed, tested and implemented in a set time frame. I would rather see a release cycle of every 3-4 months with 5 new features than a release with 15 new features which may or may not get released every 9 - 12 months. By any means, please comment if someone disagrees or thinks there is a better alternative. Andrei - Original Message - > From: "ilya" > To: dev@cloudstack.apache.org > Sent: Tuesday, 21 April, 2015 7:30:34 PM > Subject: Re: Next ACS release? > Andrei, > To best of my knowledge, both 4.4.x and 4.5.x are being worked on > actively. As a community, we need to get better on QA of each release > - > this is something we are planning to cover this year with distributed > QA model, this was not widely discussed yet but something we need to > tackle. > 4.5 rc2 got stalled and we need to restart. We had a 4 month release > cycle, but we can really stick to it hard - as its community driven. > May > will have to revise it down to 6 months or so. > Regards > ilya > On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: > > Hello guys, > > > > Looking at the dev and user lists it is becoming less certain if > > version 4.5.x is ever coming out. It seems like a few months have > > passed since the not so fortunate release of 4.5.0 and I can't find > > a release schedule for the 4.5.1, which seems to have stopped at rc2 > > stage and haven't progressed further to a release stage. > > > > Are we likely to see any progress with the 4.5.x branch or is the > > community switching towards the 4.6.x branch without releasing the > > 4.5.x? > > > > I am a bit unclear as there are no release dates, schedules or dead > > lines that the community should work with. Possibly as a result of > > this, the ACS releases are not being released on time or fast > > enough. > > > > Does it make sense to introduce release schedules for ACS that the > > dev community should stick to? Similar to what is being done in many > > other projects, like Ubuntu, etc. Or would this break the ACS > > project releases even more? > > > > Andrei > >
Re: Next ACS release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2015 12:38 AM, Andrei Mikhailovsky wrote: > Ilya, Mark, thanks for your feedback, > > I also see the need to restructure the release schedule for ACS as > the current release cycles are not really working. There is no > _reliable_ release cycle of the product and as we have recently > seen with the 4.5 branch, the release did not happen for months and > it is still not clear when this will take place. In my (I must > admit somewhat limited) experience if there are no deadlines, > developers are not keen on releases and the release are likely to > be delayed. This is what we've seen with the past ACS releases, > they are overdue by many months. > > The community might get a much better responce if there is a much > shorter release cycle even if it means pushing out less features > with each release. At least some features will get completed, > tested and implemented in a set time frame. I would rather see a > release cycle of every 3-4 months with 5 new features than a > release with 15 new features which may or may not get released > every 9 - 12 months. > > By any means, please comment if someone disagrees or thinks there > is a better alternative. > Well, one of my comments on this is that you expect the developers to have all the time available to actually work on this. Remember that most people have a $dayjob on which they need to focus and that finding the time to work on ACS is sometimes difficult. Myself for example, the last few months I haven't been able to work on ACS as much as I wanted to. My TODO list is full of things I want to work on, but simply can't get to. I can imagine this happens with more developers, they can't find the time to work on ACS. So as much as I would love to see very frequent releases of ACS, we also have to think about the resources which are required to make that happen. In the end it all comes down to more hands writing code and doing stuff for the project. Wido > Andrei - Original Message - > >> From: "ilya" To: >> dev@cloudstack.apache.org Sent: Tuesday, 21 April, 2015 7:30:34 >> PM Subject: Re: Next ACS release? > >> Andrei, > >> To best of my knowledge, both 4.4.x and 4.5.x are being worked >> on actively. As a community, we need to get better on QA of each >> release - this is something we are planning to cover this year >> with distributed QA model, this was not widely discussed yet but >> something we need to tackle. > >> 4.5 rc2 got stalled and we need to restart. We had a 4 month >> release cycle, but we can really stick to it hard - as its >> community driven. May will have to revise it down to 6 months or >> so. > >> Regards ilya > >> On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: >>> Hello guys, >>> >>> Looking at the dev and user lists it is becoming less certain >>> if version 4.5.x is ever coming out. It seems like a few months >>> have passed since the not so fortunate release of 4.5.0 and I >>> can't find a release schedule for the 4.5.1, which seems to >>> have stopped at rc2 stage and haven't progressed further to a >>> release stage. >>> >>> Are we likely to see any progress with the 4.5.x branch or is >>> the community switching towards the 4.6.x branch without >>> releasing the 4.5.x? >>> >>> I am a bit unclear as there are no release dates, schedules or >>> dead lines that the community should work with. Possibly as a >>> result of this, the ACS releases are not being released on time >>> or fast enough. >>> >>> Does it make sense to introduce release schedules for ACS that >>> the dev community should stick to? Similar to what is being >>> done in many other projects, like Ubuntu, etc. Or would this >>> break the ACS project releases even more? >>> >>> Andrei >>> > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVN0pnAAoJEAGbWC3bPspCj9oP/A+wBs47t3lEWLgb/LOAEeC/ oCDypTH+iBrX6sFdcD+HYof+XI979z6T70gYBxHYfxTxnscPOdQfdtWMHsUBkY6w /UVeWkMQl7RwmnN8Uq2ASNSVoTe9rLSxXkjjvrDMO4mcjnNSEkWKv2tk5lC1o0ac ryN01Acs/usZSJ5VdmaW/ixgVdeEV1qbCD20OIq4/z/vnmy+Ef+ui0GkopltlZ8I bzPhRX6Dj4LAFujlVaIuxR/hbV7z9GJi6YMcPTB9GfdgM4cZVUYl802UZ0NGvnzg 7lW4CdSa0obM2HeakpdH1VGaWr4TxjVROaOZjZ8VkzDXOS0rJ0HgWktvk5z+uZXh GSNgAlkWQoGhcP20Mls23WcGGktveLHxzfbAVDo7YSS5a/Q7ejDVVMVL1T/w7P0V I7l/TCTkGYZHRTBrQxMSTRoW1Ieo192opAio09y12KtMeb7rpvh0OD6kHpkgHaoB 6uXWmOqy1eUnqkS5NxfecV+f6weNpHioug0irrLfqiZPA2PmnrNJzMNATR9AqbxB 1ohOwoPr8Rewbm96RtgsAR+/8yroLbPL0lHZni5AKklvdUlEL28vzT0ceve7tua3 anzLX4PLkXuzKrWNzawQbdr+5el/CvJW3pZ3yNlNG+b4qgskBmy3Sub/9S2dnDrp +u5v88xGl5YFWpefLKb0 =FIJ3 -END PGP SIGNATURE-
Re: Next ACS release?
Ilya, Mark, thanks for your feedback, I also see the need to restructure the release schedule for ACS as the current release cycles are not really working. There is no _reliable_ release cycle of the product and as we have recently seen with the 4.5 branch, the release did not happen for months and it is still not clear when this will take place. In my (I must admit somewhat limited) experience if there are no deadlines, developers are not keen on releases and the release are likely to be delayed. This is what we've seen with the past ACS releases, they are overdue by many months. The community might get a much better responce if there is a much shorter release cycle even if it means pushing out less features with each release. At least some features will get completed, tested and implemented in a set time frame. I would rather see a release cycle of every 3-4 months with 5 new features than a release with 15 new features which may or may not get released every 9 - 12 months. By any means, please comment if someone disagrees or thinks there is a better alternative. Andrei - Original Message - > From: "ilya" > To: dev@cloudstack.apache.org > Sent: Tuesday, 21 April, 2015 7:30:34 PM > Subject: Re: Next ACS release? > Andrei, > To best of my knowledge, both 4.4.x and 4.5.x are being worked on > actively. As a community, we need to get better on QA of each release > - > this is something we are planning to cover this year with distributed > QA > model, this was not widely discussed yet but something we need to > tackle. > 4.5 rc2 got stalled and we need to restart. We had a 4 month release > cycle, but we can really stick to it hard - as its community driven. > May > will have to revise it down to 6 months or so. > Regards > ilya > On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: > > Hello guys, > > > > Looking at the dev and user lists it is becoming less certain if > > version 4.5.x is ever coming out. It seems like a few months have > > passed since the not so fortunate release of 4.5.0 and I can't > > find a release schedule for the 4.5.1, which seems to have stopped > > at rc2 stage and haven't progressed further to a release stage. > > > > Are we likely to see any progress with the 4.5.x branch or is the > > community switching towards the 4.6.x branch without releasing the > > 4.5.x? > > > > I am a bit unclear as there are no release dates, schedules or dead > > lines that the community should work with. Possibly as a result of > > this, the ACS releases are not being released on time or fast > > enough. > > > > Does it make sense to introduce release schedules for ACS that the > > dev community should stick to? Similar to what is being done in > > many other projects, like Ubuntu, etc. Or would this break the ACS > > project releases even more? > > > > Andrei > >
Re: Next ACS release?
Andrei, To best of my knowledge, both 4.4.x and 4.5.x are being worked on actively. As a community, we need to get better on QA of each release - this is something we are planning to cover this year with distributed QA model, this was not widely discussed yet but something we need to tackle. 4.5 rc2 got stalled and we need to restart. We had a 4 month release cycle, but we can really stick to it hard - as its community driven. May will have to revise it down to 6 months or so. Regards ilya On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: Hello guys, Looking at the dev and user lists it is becoming less certain if version 4.5.x is ever coming out. It seems like a few months have passed since the not so fortunate release of 4.5.0 and I can't find a release schedule for the 4.5.1, which seems to have stopped at rc2 stage and haven't progressed further to a release stage. Are we likely to see any progress with the 4.5.x branch or is the community switching towards the 4.6.x branch without releasing the 4.5.x? I am a bit unclear as there are no release dates, schedules or dead lines that the community should work with. Possibly as a result of this, the ACS releases are not being released on time or fast enough. Does it make sense to introduce release schedules for ACS that the dev community should stick to? Similar to what is being done in many other projects, like Ubuntu, etc. Or would this break the ACS project releases even more? Andrei
Re: Next ACS release?
Andrei, we just released 4.4.3 save the release notes and hence the announcement. Full focus should be on stabalizing and finalizing 4.5.1, now. We didn't discuss going forth with 4.6 yet, though the topic of release management for 4.6 has passed the dev list. Are there any concerns you have with the 4.5 release in particular? The idea of abandoning 4.5 in favour of 4.6 does not appeal to me much. We at our shop will probably be skipping 4.5.. I can not say much on release schedule/dates. I think making fixed promises makes only sense if we can easily abandon features that are proven to be unstable. At the moment our release process doesn't facilitate this. So the answer to your last question is yes. We are working to move away from this impediment and will probably vote for fixed short release cycles in the future where fixes go in 2 to 4 week cycles and features in 2 to 4 month cycles. Hope you agree. If not, this discussion is still open. On Tue, Apr 21, 2015 at 10:26 AM, Andrei Mikhailovsky wrote: > Hello guys, > > Looking at the dev and user lists it is becoming less certain if version > 4.5.x is ever coming out. It seems like a few months have passed since the > not so fortunate release of 4.5.0 and I can't find a release schedule for the > 4.5.1, which seems to have stopped at rc2 stage and haven't progressed > further to a release stage. > > Are we likely to see any progress with the 4.5.x branch or is the community > switching towards the 4.6.x branch without releasing the 4.5.x? > > I am a bit unclear as there are no release dates, schedules or dead lines > that the community should work with. Possibly as a result of this, the ACS > releases are not being released on time or fast enough. > > Does it make sense to introduce release schedules for ACS that the dev > community should stick to? Similar to what is being done in many other > projects, like Ubuntu, etc. Or would this break the ACS project releases even > more? > > Andrei -- Daan
Next ACS release?
Hello guys, Looking at the dev and user lists it is becoming less certain if version 4.5.x is ever coming out. It seems like a few months have passed since the not so fortunate release of 4.5.0 and I can't find a release schedule for the 4.5.1, which seems to have stopped at rc2 stage and haven't progressed further to a release stage. Are we likely to see any progress with the 4.5.x branch or is the community switching towards the 4.6.x branch without releasing the 4.5.x? I am a bit unclear as there are no release dates, schedules or dead lines that the community should work with. Possibly as a result of this, the ACS releases are not being released on time or fast enough. Does it make sense to introduce release schedules for ACS that the dev community should stick to? Similar to what is being done in many other projects, like Ubuntu, etc. Or would this break the ACS project releases even more? Andrei
