You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2014/03/01 00:31:18 UTC
Re: 4.4 Feature Freeze
Again...it's not going to break my heart personally if we keep the current
feature freeze date or not (my code should be in soon), but I do think we
need to get a bit real if we expect anyone who's working on a future
release to help out testing RC builds.
I expect most people would prefer you help out on testing RC builds rather
than you move forward with development on master. However, in the current
model, you're incented a bit to ignore the RC builds and continue on with
development on master if testing RCs is going to stop you from getting a
feature into the next release. It's especially easy to ignore testing RC
builds when there are six of them.
On Fri, Feb 28, 2014 at 2:08 PM, John Kinsella <jl...@stratosec.co> wrote:
> I'm completely in-line with Hugo on this. Was actually going to make
> similar comments about the...solidness of the arguments to move.
>
> On Feb 28, 2014, at 6:09 AM, Hugo Trippaers <hugo@trippaers.nl<mailto:
> hugo@trippaers.nl>> wrote:
>
> i'm all for being flexible, but i find a lot of the arguments used here
> debatable.
>
> "It causes developers to rush their development to meet the deadline."
> This will happen anyway, every time we've extended the deadline we got new
> features coming in at the last minute. Actually i'm under the impression
> that when we move the deadline people will actually try to get more
> features in instead of working on stabilizing existing features.
>
> "We can't deliver features on the roadmap." There is validity to this
> point, but on the other hand we already know the entire release schedule
> way ahead, this feature freeze date should not come as a surprise. But as i
> mentioned in an earlier mail, lets have this discussion. Post which
> features might not make it into the release so we can have a discussion if
> we should slip the release date to get this feature in. I think we all now
> that there are commercial parties working with this software to build
> releases and have customers demanding features, but if we don't discuss
> that on list it's hard for us to take it into account.
>
> "Feature freeze wasn't called" True, i wasn't even aware that this was a
> requirement. We should add this to the procedure here
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
> release managers know this is expected of them. It should not impact the
> dates as the dates are already fixed by the release schedule (every 4
> months)
>
>
> I'm still -1 on extending the feature freeze. I would rather extend the
> test/stability phase to we have some more time to fix issues before we get
> into the RC spinning.
>
>
> This is the list of current features targeted for 4.4 according to our
> Jira. Which features would be impacted if we don't move the feature freeze?
>
> ASF JIRA
> Project: CloudStack
> Type: New Feature
> Fix Version: 4.4.0
> Resolution: Unresolved
> Sorted by: Updated descending
> 1-15 of 15 as at: 28/Feb/14 15:07
> T Key Summary Assignee Reporter P Status Resolution Created Updated Due
> <newfeature.png> CLOUDSTACK-6181
> Root resize
> Unassigned Nux <major.png> <open.png> Open Unresolved 27/Feb/14 27/Feb/14
> <newfeature.png> CLOUDSTACK-6161
> distributed routing and network ACL with OVS plug-in
> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 24/Feb/14
> 24/Feb/14
> <newfeature.png> CLOUDSTACK-6092
> Storage OverProvisioning as a Per Primary Basis
> Saksham Srivastava Saksham Srivastava <major.png> <open.png> Open
> Unresolved 13/Feb/14 20/Feb/14
> <newfeature.png> CLOUDSTACK-6144
> HA for guest VMs running Hyper-V
> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
> 20/Feb/14
> <newfeature.png> CLOUDSTACK-6143
> Storage Live-Migration support for Hyper-V
> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
> 20/Feb/14
> <newfeature.png> CLOUDSTACK-6142
> Zone Wide Primary Store in Hyper-V
> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
> 20/Feb/14
> <newfeature.png> CLOUDSTACK-6104
> PVLAN support for CloudStack deployment over Nexus 1000v in VMware
> environment
> Sateesh Chodapuneedi Sateesh Chodapuneedi <major.png> <open.png> Open
> Unresolved 14/Feb/14 15/Feb/14
> <newfeature.png> CLOUDSTACK-6109
> Support of iSCSI as primary store in Hyper-V
> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
> 14/Feb/14 14/Feb/14
> <newfeature.png> CLOUDSTACK-6106
> Support of VPC in HyperV
> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
> 14/Feb/14 14/Feb/14
> <newfeature.png> CLOUDSTACK-6090
> Virtual Router Service Failure Alerting
> Harikrishna Patnala Harikrishna Patnala <major.png> <open.png> Open
> Unresolved 13/Feb/14 13/Feb/14
> <newfeature.png> CLOUDSTACK-6052
> List VM enhancement to support querying with multiple VM IDs
> Koushik Das Koushik Das <major.png> <open.png> Open Unresolved 07/Feb/14
> 07/Feb/14
> <newfeature.png> CLOUDSTACK-5569
> enhance OVS plug-in to support region level VPC and guest networks that
> span zones
> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
> 19/Dec/13
> <newfeature.png> CLOUDSTACK-5568
> introduce notion of guest network that spans multiple zones
> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
> 19/Dec/13
> <newfeature.png> CLOUDSTACK-5567
> enable VPC at region level
> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
> 19/Dec/13
> <newfeature.png> CLOUDSTACK-5398
> Cloudstack network-element plugin to orchestrate Juniper's switches
> Unassigned Pradeep H Krishnamurthy <major.png> <open.png> Open Unresolved
> 06/Dec/13 06/Dec/13
>
>
>
> Cheers,
>
> Hugo
>
> On 28 feb. 2014, at 10:17, Prasanna Santhanam <tsp@apache.org<mailto:
> tsp@apache.org>> wrote:
>
> On Fri, Feb 28, 2014 at 07:26:10AM +0000, Ram Ganesh wrote:
> Yes. I can only agree with you on this. When we come up with dates
> we have to be cognizant about slips in prior releases (we had 6 RC
> re-spins and counting....) which would have had impact which is the
> case now. We have to be bit flexible with our dates.
>
>
> But you do agree that the re-spins uncovered bugs/issues that needed
> to be fixed? Is it perhaps a mismatch in when the artifacts start
> getting tested by the users+devs as opposed to when company-x might be
> satisfied with their testing? More than 90% of the re-spins are
> bugs/issues uncovered by users who needed RC candidates and weren't
> testing artifacts on a daily basis (I could be wrong here). I don't
> think someone with a large test engineering team would wait for the
> RCs to get rolling. May be if we addressed that mismatch in timing we
> could have smaller RC phases. Something like a soft-freeze and a
> hard-freeze.
>
> post soft-freeze : users+devs do a daily test (mostly manually for
> features they care about)
> post hard-freeze : everyone only looks at a daily automated test
> report and if all looks good, we release?
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com<http://bigrock.com/>
>
>
>
> Stratosec<http://stratosec.co/> - Compliance as a Service
> o: 415.315.9385
> @johnlkinsella<http://twitter.com/johnlkinsella>
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Re: 4.4 Feature Freeze
Posted by Marcus <sh...@gmail.com>.
I don't know. I do think we should stick to a schedule, but I also
think that the track record has shown that there are far too many
features stuffed into our releases to have such short release cycles.
Part of the point of short release cycles (assuming you consider 4
months to be short, with a chunk of that being frozen from commits) is
to roll fewer, incremental changes often rather than a large number of
changes. We seem to have a lot of changes that by the time they're
merged *mostly* work, and then we spend 3-4 months just fixing the
bugs and then talk about pushing out the next release. This has
happened every release since I've been a part of the project. A year
ago this month we were talking about Spring, and arguments were being
made that not including spring in 4.1 at the last moment would punish
those who worked so hard on it, and then 4.1 got delayed for several
months due to that and other issues. We have to move beyond the
'punishment' mentality if we do actually still want to stick to a
schedule, because it promotes pushing unfinished code into a release.
It's not that I don't understand wanting to merge a feature early, or
not work on it for several releases. Huge swaths of code get changed
every release, and not just due to features. Sometimes it seems as
though there are a few people whose job is just to reorganize/split
classes :-) It's very difficult to keep a feature branch working and
up-to-date with master, and it's telling I think that features are
generally started and merged in the same window (the one exception I
can remember is the storage refactor). I wouldn't expect that with
such a complex piece of software, but when core components change
every release it's difficult to develop across cycles.
I think if we mess with the timeline it may not do much good until we
figure out how to stop breaking things/introducing bugs when we merge
features. If we stretch out testing, people still won't play with it
until RC time. Playing with the merge window will only adjust how bad
it is (which perhaps is better than nothing) when we go to RC.
On Fri, Feb 28, 2014 at 5:46 PM, Sheng Yang <sh...@yasker.org> wrote:
> As Mike said, due to our long RC process, maintain the original
> timeline is basically means PENALTY for people working on current
> release: if people works on testing/fixing the previous release, then
> the time left for them into new release would be much shorter. In our
> current case, likely 2 weeks. I don't think it would make any sense.
>
> Also, keep the current schedule in the future would also means
> discourage people from testing RC release - if I need to choose only
> one between developing my feature in the new release(which bound to a
> timeline) or testing current release's RC(which can last two month
> without anyone see the end, due to various reason), who would do the
> latter? I believe many developers/companies involved here would have
> feature/timeline for release.
>
> I don't want to say it's correct or not for now to stick with our "4
> month release cycle" since we once agreed on it, but please do put the
> RC process into consideration. How many weeks we have after 4.2
> release for new features in 4.3? How many weeks after 4.3 release for
> new features in 4.4? I don't believe we want to discourage people from
> testing the current release by any meanings, but that's the point our
> current schedule implies.
>
> --Sheng
>
> On Fri, Feb 28, 2014 at 3:31 PM, Mike Tutkowski
> <mi...@solidfire.com> wrote:
>> Again...it's not going to break my heart personally if we keep the current
>> feature freeze date or not (my code should be in soon), but I do think we
>> need to get a bit real if we expect anyone who's working on a future
>> release to help out testing RC builds.
>>
>> I expect most people would prefer you help out on testing RC builds rather
>> than you move forward with development on master. However, in the current
>> model, you're incented a bit to ignore the RC builds and continue on with
>> development on master if testing RCs is going to stop you from getting a
>> feature into the next release. It's especially easy to ignore testing RC
>> builds when there are six of them.
>>
>>
>> On Fri, Feb 28, 2014 at 2:08 PM, John Kinsella <jl...@stratosec.co> wrote:
>>
>>> I'm completely in-line with Hugo on this. Was actually going to make
>>> similar comments about the...solidness of the arguments to move.
>>>
>>> On Feb 28, 2014, at 6:09 AM, Hugo Trippaers <hugo@trippaers.nl<mailto:
>>> hugo@trippaers.nl>> wrote:
>>>
>>> i'm all for being flexible, but i find a lot of the arguments used here
>>> debatable.
>>>
>>> "It causes developers to rush their development to meet the deadline."
>>> This will happen anyway, every time we've extended the deadline we got new
>>> features coming in at the last minute. Actually i'm under the impression
>>> that when we move the deadline people will actually try to get more
>>> features in instead of working on stabilizing existing features.
>>>
>>> "We can't deliver features on the roadmap." There is validity to this
>>> point, but on the other hand we already know the entire release schedule
>>> way ahead, this feature freeze date should not come as a surprise. But as i
>>> mentioned in an earlier mail, lets have this discussion. Post which
>>> features might not make it into the release so we can have a discussion if
>>> we should slip the release date to get this feature in. I think we all now
>>> that there are commercial parties working with this software to build
>>> releases and have customers demanding features, but if we don't discuss
>>> that on list it's hard for us to take it into account.
>>>
>>> "Feature freeze wasn't called" True, i wasn't even aware that this was a
>>> requirement. We should add this to the procedure here
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
>>> release managers know this is expected of them. It should not impact the
>>> dates as the dates are already fixed by the release schedule (every 4
>>> months)
>>>
>>>
>>> I'm still -1 on extending the feature freeze. I would rather extend the
>>> test/stability phase to we have some more time to fix issues before we get
>>> into the RC spinning.
>>>
>>>
>>> This is the list of current features targeted for 4.4 according to our
>>> Jira. Which features would be impacted if we don't move the feature freeze?
>>>
>>> ASF JIRA
>>> Project: CloudStack
>>> Type: New Feature
>>> Fix Version: 4.4.0
>>> Resolution: Unresolved
>>> Sorted by: Updated descending
>>> 1-15 of 15 as at: 28/Feb/14 15:07
>>> T Key Summary Assignee Reporter P Status Resolution Created Updated Due
>>> <newfeature.png> CLOUDSTACK-6181
>>> Root resize
>>> Unassigned Nux <major.png> <open.png> Open Unresolved 27/Feb/14 27/Feb/14
>>> <newfeature.png> CLOUDSTACK-6161
>>> distributed routing and network ACL with OVS plug-in
>>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 24/Feb/14
>>> 24/Feb/14
>>> <newfeature.png> CLOUDSTACK-6092
>>> Storage OverProvisioning as a Per Primary Basis
>>> Saksham Srivastava Saksham Srivastava <major.png> <open.png> Open
>>> Unresolved 13/Feb/14 20/Feb/14
>>> <newfeature.png> CLOUDSTACK-6144
>>> HA for guest VMs running Hyper-V
>>> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
>>> 20/Feb/14
>>> <newfeature.png> CLOUDSTACK-6143
>>> Storage Live-Migration support for Hyper-V
>>> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
>>> 20/Feb/14
>>> <newfeature.png> CLOUDSTACK-6142
>>> Zone Wide Primary Store in Hyper-V
>>> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
>>> 20/Feb/14
>>> <newfeature.png> CLOUDSTACK-6104
>>> PVLAN support for CloudStack deployment over Nexus 1000v in VMware
>>> environment
>>> Sateesh Chodapuneedi Sateesh Chodapuneedi <major.png> <open.png> Open
>>> Unresolved 14/Feb/14 15/Feb/14
>>> <newfeature.png> CLOUDSTACK-6109
>>> Support of iSCSI as primary store in Hyper-V
>>> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
>>> 14/Feb/14 14/Feb/14
>>> <newfeature.png> CLOUDSTACK-6106
>>> Support of VPC in HyperV
>>> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
>>> 14/Feb/14 14/Feb/14
>>> <newfeature.png> CLOUDSTACK-6090
>>> Virtual Router Service Failure Alerting
>>> Harikrishna Patnala Harikrishna Patnala <major.png> <open.png> Open
>>> Unresolved 13/Feb/14 13/Feb/14
>>> <newfeature.png> CLOUDSTACK-6052
>>> List VM enhancement to support querying with multiple VM IDs
>>> Koushik Das Koushik Das <major.png> <open.png> Open Unresolved 07/Feb/14
>>> 07/Feb/14
>>> <newfeature.png> CLOUDSTACK-5569
>>> enhance OVS plug-in to support region level VPC and guest networks that
>>> span zones
>>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
>>> 19/Dec/13
>>> <newfeature.png> CLOUDSTACK-5568
>>> introduce notion of guest network that spans multiple zones
>>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
>>> 19/Dec/13
>>> <newfeature.png> CLOUDSTACK-5567
>>> enable VPC at region level
>>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
>>> 19/Dec/13
>>> <newfeature.png> CLOUDSTACK-5398
>>> Cloudstack network-element plugin to orchestrate Juniper's switches
>>> Unassigned Pradeep H Krishnamurthy <major.png> <open.png> Open Unresolved
>>> 06/Dec/13 06/Dec/13
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Hugo
>>>
>>> On 28 feb. 2014, at 10:17, Prasanna Santhanam <tsp@apache.org<mailto:
>>> tsp@apache.org>> wrote:
>>>
>>> On Fri, Feb 28, 2014 at 07:26:10AM +0000, Ram Ganesh wrote:
>>> Yes. I can only agree with you on this. When we come up with dates
>>> we have to be cognizant about slips in prior releases (we had 6 RC
>>> re-spins and counting....) which would have had impact which is the
>>> case now. We have to be bit flexible with our dates.
>>>
>>>
>>> But you do agree that the re-spins uncovered bugs/issues that needed
>>> to be fixed? Is it perhaps a mismatch in when the artifacts start
>>> getting tested by the users+devs as opposed to when company-x might be
>>> satisfied with their testing? More than 90% of the re-spins are
>>> bugs/issues uncovered by users who needed RC candidates and weren't
>>> testing artifacts on a daily basis (I could be wrong here). I don't
>>> think someone with a large test engineering team would wait for the
>>> RCs to get rolling. May be if we addressed that mismatch in timing we
>>> could have smaller RC phases. Something like a soft-freeze and a
>>> hard-freeze.
>>>
>>> post soft-freeze : users+devs do a daily test (mostly manually for
>>> features they care about)
>>> post hard-freeze : everyone only looks at a daily automated test
>>> report and if all looks good, we release?
>>>
>>> --
>>> Prasanna.,
>>>
>>> ------------------------
>>> Powered by BigRock.com<http://bigrock.com/>
>>>
>>>
>>>
>>> Stratosec<http://stratosec.co/> - Compliance as a Service
>>> o: 415.315.9385
>>> @johnlkinsella<http://twitter.com/johnlkinsella>
>>>
>>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> *(tm)*
Re: 4.4 Feature Freeze
Posted by Sheng Yang <sh...@yasker.org>.
As Mike said, due to our long RC process, maintain the original
timeline is basically means PENALTY for people working on current
release: if people works on testing/fixing the previous release, then
the time left for them into new release would be much shorter. In our
current case, likely 2 weeks. I don't think it would make any sense.
Also, keep the current schedule in the future would also means
discourage people from testing RC release - if I need to choose only
one between developing my feature in the new release(which bound to a
timeline) or testing current release's RC(which can last two month
without anyone see the end, due to various reason), who would do the
latter? I believe many developers/companies involved here would have
feature/timeline for release.
I don't want to say it's correct or not for now to stick with our "4
month release cycle" since we once agreed on it, but please do put the
RC process into consideration. How many weeks we have after 4.2
release for new features in 4.3? How many weeks after 4.3 release for
new features in 4.4? I don't believe we want to discourage people from
testing the current release by any meanings, but that's the point our
current schedule implies.
--Sheng
On Fri, Feb 28, 2014 at 3:31 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> Again...it's not going to break my heart personally if we keep the current
> feature freeze date or not (my code should be in soon), but I do think we
> need to get a bit real if we expect anyone who's working on a future
> release to help out testing RC builds.
>
> I expect most people would prefer you help out on testing RC builds rather
> than you move forward with development on master. However, in the current
> model, you're incented a bit to ignore the RC builds and continue on with
> development on master if testing RCs is going to stop you from getting a
> feature into the next release. It's especially easy to ignore testing RC
> builds when there are six of them.
>
>
> On Fri, Feb 28, 2014 at 2:08 PM, John Kinsella <jl...@stratosec.co> wrote:
>
>> I'm completely in-line with Hugo on this. Was actually going to make
>> similar comments about the...solidness of the arguments to move.
>>
>> On Feb 28, 2014, at 6:09 AM, Hugo Trippaers <hugo@trippaers.nl<mailto:
>> hugo@trippaers.nl>> wrote:
>>
>> i'm all for being flexible, but i find a lot of the arguments used here
>> debatable.
>>
>> "It causes developers to rush their development to meet the deadline."
>> This will happen anyway, every time we've extended the deadline we got new
>> features coming in at the last minute. Actually i'm under the impression
>> that when we move the deadline people will actually try to get more
>> features in instead of working on stabilizing existing features.
>>
>> "We can't deliver features on the roadmap." There is validity to this
>> point, but on the other hand we already know the entire release schedule
>> way ahead, this feature freeze date should not come as a surprise. But as i
>> mentioned in an earlier mail, lets have this discussion. Post which
>> features might not make it into the release so we can have a discussion if
>> we should slip the release date to get this feature in. I think we all now
>> that there are commercial parties working with this software to build
>> releases and have customers demanding features, but if we don't discuss
>> that on list it's hard for us to take it into account.
>>
>> "Feature freeze wasn't called" True, i wasn't even aware that this was a
>> requirement. We should add this to the procedure here
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
>> release managers know this is expected of them. It should not impact the
>> dates as the dates are already fixed by the release schedule (every 4
>> months)
>>
>>
>> I'm still -1 on extending the feature freeze. I would rather extend the
>> test/stability phase to we have some more time to fix issues before we get
>> into the RC spinning.
>>
>>
>> This is the list of current features targeted for 4.4 according to our
>> Jira. Which features would be impacted if we don't move the feature freeze?
>>
>> ASF JIRA
>> Project: CloudStack
>> Type: New Feature
>> Fix Version: 4.4.0
>> Resolution: Unresolved
>> Sorted by: Updated descending
>> 1-15 of 15 as at: 28/Feb/14 15:07
>> T Key Summary Assignee Reporter P Status Resolution Created Updated Due
>> <newfeature.png> CLOUDSTACK-6181
>> Root resize
>> Unassigned Nux <major.png> <open.png> Open Unresolved 27/Feb/14 27/Feb/14
>> <newfeature.png> CLOUDSTACK-6161
>> distributed routing and network ACL with OVS plug-in
>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 24/Feb/14
>> 24/Feb/14
>> <newfeature.png> CLOUDSTACK-6092
>> Storage OverProvisioning as a Per Primary Basis
>> Saksham Srivastava Saksham Srivastava <major.png> <open.png> Open
>> Unresolved 13/Feb/14 20/Feb/14
>> <newfeature.png> CLOUDSTACK-6144
>> HA for guest VMs running Hyper-V
>> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
>> 20/Feb/14
>> <newfeature.png> CLOUDSTACK-6143
>> Storage Live-Migration support for Hyper-V
>> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
>> 20/Feb/14
>> <newfeature.png> CLOUDSTACK-6142
>> Zone Wide Primary Store in Hyper-V
>> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved 20/Feb/14
>> 20/Feb/14
>> <newfeature.png> CLOUDSTACK-6104
>> PVLAN support for CloudStack deployment over Nexus 1000v in VMware
>> environment
>> Sateesh Chodapuneedi Sateesh Chodapuneedi <major.png> <open.png> Open
>> Unresolved 14/Feb/14 15/Feb/14
>> <newfeature.png> CLOUDSTACK-6109
>> Support of iSCSI as primary store in Hyper-V
>> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
>> 14/Feb/14 14/Feb/14
>> <newfeature.png> CLOUDSTACK-6106
>> Support of VPC in HyperV
>> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
>> 14/Feb/14 14/Feb/14
>> <newfeature.png> CLOUDSTACK-6090
>> Virtual Router Service Failure Alerting
>> Harikrishna Patnala Harikrishna Patnala <major.png> <open.png> Open
>> Unresolved 13/Feb/14 13/Feb/14
>> <newfeature.png> CLOUDSTACK-6052
>> List VM enhancement to support querying with multiple VM IDs
>> Koushik Das Koushik Das <major.png> <open.png> Open Unresolved 07/Feb/14
>> 07/Feb/14
>> <newfeature.png> CLOUDSTACK-5569
>> enhance OVS plug-in to support region level VPC and guest networks that
>> span zones
>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
>> 19/Dec/13
>> <newfeature.png> CLOUDSTACK-5568
>> introduce notion of guest network that spans multiple zones
>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
>> 19/Dec/13
>> <newfeature.png> CLOUDSTACK-5567
>> enable VPC at region level
>> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
>> 19/Dec/13
>> <newfeature.png> CLOUDSTACK-5398
>> Cloudstack network-element plugin to orchestrate Juniper's switches
>> Unassigned Pradeep H Krishnamurthy <major.png> <open.png> Open Unresolved
>> 06/Dec/13 06/Dec/13
>>
>>
>>
>> Cheers,
>>
>> Hugo
>>
>> On 28 feb. 2014, at 10:17, Prasanna Santhanam <tsp@apache.org<mailto:
>> tsp@apache.org>> wrote:
>>
>> On Fri, Feb 28, 2014 at 07:26:10AM +0000, Ram Ganesh wrote:
>> Yes. I can only agree with you on this. When we come up with dates
>> we have to be cognizant about slips in prior releases (we had 6 RC
>> re-spins and counting....) which would have had impact which is the
>> case now. We have to be bit flexible with our dates.
>>
>>
>> But you do agree that the re-spins uncovered bugs/issues that needed
>> to be fixed? Is it perhaps a mismatch in when the artifacts start
>> getting tested by the users+devs as opposed to when company-x might be
>> satisfied with their testing? More than 90% of the re-spins are
>> bugs/issues uncovered by users who needed RC candidates and weren't
>> testing artifacts on a daily basis (I could be wrong here). I don't
>> think someone with a large test engineering team would wait for the
>> RCs to get rolling. May be if we addressed that mismatch in timing we
>> could have smaller RC phases. Something like a soft-freeze and a
>> hard-freeze.
>>
>> post soft-freeze : users+devs do a daily test (mostly manually for
>> features they care about)
>> post hard-freeze : everyone only looks at a daily automated test
>> report and if all looks good, we release?
>>
>> --
>> Prasanna.,
>>
>> ------------------------
>> Powered by BigRock.com<http://bigrock.com/>
>>
>>
>>
>> Stratosec<http://stratosec.co/> - Compliance as a Service
>> o: 415.315.9385
>> @johnlkinsella<http://twitter.com/johnlkinsella>
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*
RE: 4.4 Feature Freeze
Posted by Prachi Damle <Pr...@citrix.com>.
+1 for pushing out the feature freeze to 3/28.
Most of us have been busy with 4.3 and so it will be good to have some extra room to focus fully on our 4.4 features.
Myself and Min are working on the IAM feature (https://issues.apache.org/jira/browse/CLOUDSTACK-5920) and I feel that 3/28 will give us some room to test our code and add better integration tests.
Current integration tests do not focus on testing IAM functionality with default roles (user/domainadmin/admin) at all. So it is good to cover as many as we could.
Thanks,
Prachi
-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: Friday, February 28, 2014 3:31 PM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze
Again...it's not going to break my heart personally if we keep the current feature freeze date or not (my code should be in soon), but I do think we need to get a bit real if we expect anyone who's working on a future release to help out testing RC builds.
I expect most people would prefer you help out on testing RC builds rather than you move forward with development on master. However, in the current model, you're incented a bit to ignore the RC builds and continue on with development on master if testing RCs is going to stop you from getting a feature into the next release. It's especially easy to ignore testing RC builds when there are six of them.
On Fri, Feb 28, 2014 at 2:08 PM, John Kinsella <jl...@stratosec.co> wrote:
> I'm completely in-line with Hugo on this. Was actually going to make
> similar comments about the...solidness of the arguments to move.
>
> On Feb 28, 2014, at 6:09 AM, Hugo Trippaers <hugo@trippaers.nl<mailto:
> hugo@trippaers.nl>> wrote:
>
> i'm all for being flexible, but i find a lot of the arguments used
> here debatable.
>
> "It causes developers to rush their development to meet the deadline."
> This will happen anyway, every time we've extended the deadline we got
> new features coming in at the last minute. Actually i'm under the
> impression that when we move the deadline people will actually try to
> get more features in instead of working on stabilizing existing features.
>
> "We can't deliver features on the roadmap." There is validity to this
> point, but on the other hand we already know the entire release
> schedule way ahead, this feature freeze date should not come as a
> surprise. But as i mentioned in an earlier mail, lets have this
> discussion. Post which features might not make it into the release so
> we can have a discussion if we should slip the release date to get
> this feature in. I think we all now that there are commercial parties
> working with this software to build releases and have customers
> demanding features, but if we don't discuss that on list it's hard for us to take it into account.
>
> "Feature freeze wasn't called" True, i wasn't even aware that this was
> a requirement. We should add this to the procedure here
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases so
> release managers know this is expected of them. It should not impact
> the dates as the dates are already fixed by the release schedule
> (every 4
> months)
>
>
> I'm still -1 on extending the feature freeze. I would rather extend
> the test/stability phase to we have some more time to fix issues
> before we get into the RC spinning.
>
>
> This is the list of current features targeted for 4.4 according to our
> Jira. Which features would be impacted if we don't move the feature freeze?
>
> ASF JIRA
> Project: CloudStack
> Type: New Feature
> Fix Version: 4.4.0
> Resolution: Unresolved
> Sorted by: Updated descending
> 1-15 of 15 as at: 28/Feb/14 15:07
> T Key Summary Assignee Reporter P Status Resolution Created Updated
> Due <newfeature.png> CLOUDSTACK-6181 Root resize Unassigned Nux
> <major.png> <open.png> Open Unresolved 27/Feb/14 27/Feb/14
> <newfeature.png> CLOUDSTACK-6161 distributed routing and network ACL
> with OVS plug-in Murali Reddy Murali Reddy <major.png> <open.png> Open
> Unresolved 24/Feb/14
> 24/Feb/14
> <newfeature.png> CLOUDSTACK-6092
> Storage OverProvisioning as a Per Primary Basis Saksham Srivastava
> Saksham Srivastava <major.png> <open.png> Open Unresolved 13/Feb/14
> 20/Feb/14 <newfeature.png> CLOUDSTACK-6144 HA for guest VMs running
> Hyper-V Unassigned Rajesh Battala <major.png> <open.png> Open
> Unresolved 20/Feb/14
> 20/Feb/14
> <newfeature.png> CLOUDSTACK-6143
> Storage Live-Migration support for Hyper-V Unassigned Rajesh Battala
> <major.png> <open.png> Open Unresolved 20/Feb/14
> 20/Feb/14
> <newfeature.png> CLOUDSTACK-6142
> Zone Wide Primary Store in Hyper-V
> Unassigned Rajesh Battala <major.png> <open.png> Open Unresolved
> 20/Feb/14
> 20/Feb/14
> <newfeature.png> CLOUDSTACK-6104
> PVLAN support for CloudStack deployment over Nexus 1000v in VMware
> environment Sateesh Chodapuneedi Sateesh Chodapuneedi <major.png>
> <open.png> Open Unresolved 14/Feb/14 15/Feb/14 <newfeature.png>
> CLOUDSTACK-6109 Support of iSCSI as primary store in Hyper-V Rajesh
> Battala Rajesh Battala <major.png> <open.png> Open Unresolved
> 14/Feb/14 14/Feb/14
> <newfeature.png> CLOUDSTACK-6106
> Support of VPC in HyperV
> Rajesh Battala Rajesh Battala <major.png> <open.png> Open Unresolved
> 14/Feb/14 14/Feb/14
> <newfeature.png> CLOUDSTACK-6090
> Virtual Router Service Failure Alerting Harikrishna Patnala
> Harikrishna Patnala <major.png> <open.png> Open Unresolved 13/Feb/14
> 13/Feb/14 <newfeature.png> CLOUDSTACK-6052 List VM enhancement to
> support querying with multiple VM IDs Koushik Das Koushik Das
> <major.png> <open.png> Open Unresolved 07/Feb/14
> 07/Feb/14
> <newfeature.png> CLOUDSTACK-5569
> enhance OVS plug-in to support region level VPC and guest networks
> that span zones Murali Reddy Murali Reddy <major.png> <open.png> Open
> Unresolved 19/Dec/13
> 19/Dec/13
> <newfeature.png> CLOUDSTACK-5568
> introduce notion of guest network that spans multiple zones Murali
> Reddy Murali Reddy <major.png> <open.png> Open Unresolved 19/Dec/13
> 19/Dec/13
> <newfeature.png> CLOUDSTACK-5567
> enable VPC at region level
> Murali Reddy Murali Reddy <major.png> <open.png> Open Unresolved
> 19/Dec/13
> 19/Dec/13
> <newfeature.png> CLOUDSTACK-5398
> Cloudstack network-element plugin to orchestrate Juniper's switches
> Unassigned Pradeep H Krishnamurthy <major.png> <open.png> Open
> Unresolved
> 06/Dec/13 06/Dec/13
>
>
>
> Cheers,
>
> Hugo
>
> On 28 feb. 2014, at 10:17, Prasanna Santhanam <tsp@apache.org<mailto:
> tsp@apache.org>> wrote:
>
> On Fri, Feb 28, 2014 at 07:26:10AM +0000, Ram Ganesh wrote:
> Yes. I can only agree with you on this. When we come up with dates we
> have to be cognizant about slips in prior releases (we had 6 RC
> re-spins and counting....) which would have had impact which is the
> case now. We have to be bit flexible with our dates.
>
>
> But you do agree that the re-spins uncovered bugs/issues that needed
> to be fixed? Is it perhaps a mismatch in when the artifacts start
> getting tested by the users+devs as opposed to when company-x might be
> satisfied with their testing? More than 90% of the re-spins are
> bugs/issues uncovered by users who needed RC candidates and weren't
> testing artifacts on a daily basis (I could be wrong here). I don't
> think someone with a large test engineering team would wait for the
> RCs to get rolling. May be if we addressed that mismatch in timing we
> could have smaller RC phases. Something like a soft-freeze and a
> hard-freeze.
>
> post soft-freeze : users+devs do a daily test (mostly manually for
> features they care about) post hard-freeze : everyone only looks at a
> daily automated test report and if all looks good, we release?
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com<http://bigrock.com/>
>
>
>
> Stratosec<http://stratosec.co/> - Compliance as a Service
> o: 415.315.9385
> @johnlkinsella<http://twitter.com/johnlkinsella>
>
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*