3.5 Time-frame: pushing feature freeze
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work. Therefore I suggest to set an updated FF milestone for June 15. If you need more time or think we should not change the current date please respond. Thanks, Doron [1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Il 28/05/2014 17:01, Doron Fediuck ha scritto:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
+1 Will all other milestones be postponed by 2 weeks too? General availability: 2014-08-18 RC Build: 2014-07-31 oVirt 3.5 Second Test Day: 2014-07-15 Branching - Beta release: 2014-06-23 oVirt 3.5 First Test Day: 2014-06-19 Feature freeze - Second Alpha release: 2014-06-15 Or are we keeping everything else as is, just moving Feature Freeze? General availability: 2014-08-04 RC Build: 2014-07-15 oVirt 3.5 Second Test Day: 2014-07-01 Branching - Beta release: 2014-06-16 Feature freeze: 2014-06-15 oVirt 3.5 First Test Day: 2014-06-05 Second Alpha release: 2014-05-30 Is tomorrow alpha build confirmed in any case? Let me know when we have a final decision so I'll update the wiki and the Google calendar.
If you need more time or think we should not change the current date please respond.
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release. I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release. I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process): 1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!). An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs... 2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt. 3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec) 4. The release manager of the version should approve the spec for the version according to the well known deadlines. Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed. As for your suggestion I'm all for a proper discussion as it seems that the timeline wasn't kept so far and this is the last slip we can allow without changing GA date. Doron
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
As for your suggestion I'm all for a proper discussion as it seems that the timeline wasn't kept so far and this is the last slip we can allow without changing GA date.
I wonder how can we postpone FF by 6 weeks from the original date without any impact on the GA date.
Doron
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
And I agreed we will not be flexible for next version, but currently most teams are not ready yet. This is the feedback we got in the sync meeting and it cannot be ignored.
As for your suggestion I'm all for a proper discussion as it seems that the timeline wasn't kept so far and this is the last slip we can allow without changing GA date.
I wonder how can we postpone FF by 6 weeks from the original date without any impact on the GA date.
The original planning assumed this may happen, so it had sufficient slack. Once the release page is updated I'll send an update.
Doron
On Thu, May 29, 2014 at 09:10:59AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
And I agreed we will not be flexible for next version, but currently most teams are not ready yet. This is the feedback we got in the sync meeting and it cannot be ignored.
I don't think anybody suggests to ignore the feedback. As always, the question is: is the release time-based, or feature based? It is not clear to me which are the features that block the release. They should be named and prioritized. Otherwise, we'd slip dates forever. The number of non-green features in the spreadsheet http://bit.ly/17qBn6F does not match the numbers cited during the sync meeting, so I am confused. On Vdsm side I find 5 features with code in advanced stages. jsonrpc and import data domain should probably block the release. I am not sure about the rest. infra 1079821 [RFE] Prevent host fencing while kdumping Code will be in by end of May infra 1081049 [RFE] replace XML-RPC communication (engine-vdsm) with json-rpc based on bidirectional transport End of May infra 1083645 [RFE][scale]: Replace the use of oop with ioprocess Code will be in by Mid June virt 1082479 disable spice file transfer & copy and paste packaging on F19&F20 issues storage 1083307 import existing data domain coding ================================== Can we agree on a definite list of feature that must block 3.5? gluster 1040795 Gluster Volume Capacity monitoring In Progress gluster 1083583 Gluster Profile In Progress infra 1063095 [RFE][AAA] engine should have a generic LDAP provider Most code already in. Finalization and fixes by mid June infra 1090517 [RFE][AAA] Support anonymous bind for authn/authz Most code already in. Finalization and fixes by mid June infra 1090515 [RFE][AAA] Support for "hardened" AD environments with oVirt Most code already in. Finalization and fixes by mid June infra 1083993 [RFE] using foreman provider to provision bare-metal hosts Code will be in by end of May infra-cli 855724 [RFE] ovirt-engine-restapi : Statistic values representation issues In Progress infra-sdk 1069204 [RFE] Don't require live engine to generate SDK code In Progress integration 1080402 Allow setup of iSCSI based storage for hosted engine In Validation integration-dwh 1080997 DWH running on separate host In Progress integration-reports 1080998 reports running on separate host In Progress integration 1080992 websocket proxy running on separate host In Validation storage 1083310 live merge (delete snapshot) coding storage 1058160 VM Async Tasks via HSM coding storage 1055640 Get rid of storage pool metadata on master storage domain code review (90% complete) storage 1086178 SANlock fencing design virt 1083059 "Instance types (new template handling) - adding flavours" few things needs to be finished(perms,defaults,REST) virt virtio-rng support on review virt - finish remaining PPC support (block/allow specific features) on review node 875088 ovirt-node-registration - a generic node registration ETA end of May (in review) node 1038616 ovirt node support for hosted engine nodes ETA end of May (in review) node 1053435 oVirt virtual appliance In progress sla 1036731 hosted engine on iscsi In progress- should be ready by Mid June sla 1084930 CPU SLA for capping In progress- should be ready by Mid June sla 1085049 I/O SLA for capping (blkio) In progress- should be ready by Mid June sla 1093051 Integrating with Opta Planner to demonstrate a balanced cluster In progress- should be ready by Mid June sla 1069303 NUMA support in oVirt In Progress- missing UI and REST. sla 1062435 Implement REST API for oVirt scheduler In progress- should be ready by 1st week of June sla 1093038 Resource considerations for Migration in RHEV - memory Won't make it. sla 1093102 Reducing HA down-time In progress- should be ready by Mid June
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 5:32:20 PM Subject: Re: [ovirt-devel] 3.5 Time-frame: pushing feature freeze
On Thu, May 29, 2014 at 09:10:59AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
And I agreed we will not be flexible for next version, but currently most teams are not ready yet. This is the feedback we got in the sync meeting and it cannot be ignored.
I don't think anybody suggests to ignore the feedback. As always, the question is: is the release time-based, or feature based?
It is not clear to me which are the features that block the release. They should be named and prioritized. Otherwise, we'd slip dates forever.
The number of non-green features in the spreadsheet http://bit.ly/17qBn6F does not match the numbers cited during the sync meeting, so I am confused.
On Vdsm side I find 5 features with code in advanced stages. jsonrpc and import data domain should probably block the release. I am not sure about the rest.
infra 1079821 [RFE] Prevent host fencing while kdumping Code will be in by end of May infra 1081049 [RFE] replace XML-RPC communication (engine-vdsm) with json-rpc based on bidirectional transport End of May infra 1083645 [RFE][scale]: Replace the use of oop with ioprocess Code will be in by Mid June virt 1082479 disable spice file transfer & copy and paste packaging on F19&F20 issues storage 1083307 import existing data domain coding
==================================
Can we agree on a definite list of feature that must block 3.5?
gluster 1040795 Gluster Volume Capacity monitoring In Progress gluster 1083583 Gluster Profile In Progress
infra 1063095 [RFE][AAA] engine should have a generic LDAP provider Most code already in. Finalization and fixes by mid June infra 1090517 [RFE][AAA] Support anonymous bind for authn/authz Most code already in. Finalization and fixes by mid June infra 1090515 [RFE][AAA] Support for "hardened" AD environments with oVirt Most code already in. Finalization and fixes by mid June infra 1083993 [RFE] using foreman provider to provision bare-metal hosts Code will be in by end of May
infra-cli 855724 [RFE] ovirt-engine-restapi : Statistic values representation issues In Progress infra-sdk 1069204 [RFE] Don't require live engine to generate SDK code In Progress integration 1080402 Allow setup of iSCSI based storage for hosted engine In Validation integration-dwh 1080997 DWH running on separate host In Progress integration-reports 1080998 reports running on separate host In Progress integration 1080992 websocket proxy running on separate host In Validation
storage 1083310 live merge (delete snapshot) coding storage 1058160 VM Async Tasks via HSM coding storage 1055640 Get rid of storage pool metadata on master storage domain code review (90% complete) storage 1086178 SANlock fencing design
virt 1083059 "Instance types (new template handling) - adding flavours" few things needs to be finished(perms,defaults,REST) virt virtio-rng support on review virt - finish remaining PPC support (block/allow specific features) on review
node 875088 ovirt-node-registration - a generic node registration ETA end of May (in review) node 1038616 ovirt node support for hosted engine nodes ETA end of May (in review) node 1053435 oVirt virtual appliance In progress
sla 1036731 hosted engine on iscsi In progress- should be ready by Mid June sla 1084930 CPU SLA for capping In progress- should be ready by Mid June sla 1085049 I/O SLA for capping (blkio) In progress- should be ready by Mid June sla 1093051 Integrating with Opta Planner to demonstrate a balanced cluster In progress- should be ready by Mid June sla 1069303 NUMA support in oVirt In Progress- missing UI and REST. sla 1062435 Implement REST API for oVirt scheduler In progress- should be ready by 1st week of June sla 1093038 Resource considerations for Migration in RHEV - memory Won't make it. sla 1093102 Reducing HA down-time In progress- should be ready by Mid June
Dan this is why we have the sync meeting, and this is where we discuss these issues as you know. There's no point of opening this now as the question is how much time we need to postpone and not if we wish to postpone. The suggestion is for June 15 and it seems to be acceptable to everyone attended the meeting yesterday. This mail was to give a headsup for those who did not attend the meeting and give a chance for folks to ask for additional time if needed. Based on yesterday's feedback. we updated the release page to the following schedule: http://www.ovirt.org/OVirt_3.5_release-management If check the history you'll see that the GA date is the same. Doron
On Thu, May 29, 2014 at 10:49:55AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 5:32:20 PM Subject: Re: [ovirt-devel] 3.5 Time-frame: pushing feature freeze
On Thu, May 29, 2014 at 09:10:59AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote: > Hi, > The current date for feature freeze is May 30. > Based on today's weekly sync[1], it seems that most teams require > additional 2 weeks to conclude current work. > > Therefore I suggest to set an updated FF milestone for June 15. > > If you need more time or think we should not change the current > date please respond. >
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
> Thanks, > Doron > > [1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
And I agreed we will not be flexible for next version, but currently most teams are not ready yet. This is the feedback we got in the sync meeting and it cannot be ignored.
I don't think anybody suggests to ignore the feedback. As always, the question is: is the release time-based, or feature based?
It is not clear to me which are the features that block the release. They should be named and prioritized. Otherwise, we'd slip dates forever.
The number of non-green features in the spreadsheet http://bit.ly/17qBn6F does not match the numbers cited during the sync meeting, so I am confused.
On Vdsm side I find 5 features with code in advanced stages. jsonrpc and import data domain should probably block the release. I am not sure about the rest.
infra 1079821 [RFE] Prevent host fencing while kdumping Code will be in by end of May infra 1081049 [RFE] replace XML-RPC communication (engine-vdsm) with json-rpc based on bidirectional transport End of May infra 1083645 [RFE][scale]: Replace the use of oop with ioprocess Code will be in by Mid June virt 1082479 disable spice file transfer & copy and paste packaging on F19&F20 issues storage 1083307 import existing data domain coding
==================================
Can we agree on a definite list of feature that must block 3.5?
gluster 1040795 Gluster Volume Capacity monitoring In Progress gluster 1083583 Gluster Profile In Progress
infra 1063095 [RFE][AAA] engine should have a generic LDAP provider Most code already in. Finalization and fixes by mid June infra 1090517 [RFE][AAA] Support anonymous bind for authn/authz Most code already in. Finalization and fixes by mid June infra 1090515 [RFE][AAA] Support for "hardened" AD environments with oVirt Most code already in. Finalization and fixes by mid June infra 1083993 [RFE] using foreman provider to provision bare-metal hosts Code will be in by end of May
infra-cli 855724 [RFE] ovirt-engine-restapi : Statistic values representation issues In Progress infra-sdk 1069204 [RFE] Don't require live engine to generate SDK code In Progress integration 1080402 Allow setup of iSCSI based storage for hosted engine In Validation integration-dwh 1080997 DWH running on separate host In Progress integration-reports 1080998 reports running on separate host In Progress integration 1080992 websocket proxy running on separate host In Validation
storage 1083310 live merge (delete snapshot) coding storage 1058160 VM Async Tasks via HSM coding storage 1055640 Get rid of storage pool metadata on master storage domain code review (90% complete) storage 1086178 SANlock fencing design
virt 1083059 "Instance types (new template handling) - adding flavours" few things needs to be finished(perms,defaults,REST) virt virtio-rng support on review virt - finish remaining PPC support (block/allow specific features) on review
node 875088 ovirt-node-registration - a generic node registration ETA end of May (in review) node 1038616 ovirt node support for hosted engine nodes ETA end of May (in review) node 1053435 oVirt virtual appliance In progress
sla 1036731 hosted engine on iscsi In progress- should be ready by Mid June sla 1084930 CPU SLA for capping In progress- should be ready by Mid June sla 1085049 I/O SLA for capping (blkio) In progress- should be ready by Mid June sla 1093051 Integrating with Opta Planner to demonstrate a balanced cluster In progress- should be ready by Mid June sla 1069303 NUMA support in oVirt In Progress- missing UI and REST. sla 1062435 Implement REST API for oVirt scheduler In progress- should be ready by 1st week of June sla 1093038 Resource considerations for Migration in RHEV - memory Won't make it. sla 1093102 Reducing HA down-time In progress- should be ready by Mid June
Dan this is why we have the sync meeting, and this is where we discuss these issues as you know. There's no point of opening this now as the question is how much time we need to postpone and not if we wish to postpone.
The suggestion is for June 15 and it seems to be acceptable to everyone attended the meeting yesterday. This mail was to give a headsup for those who did not attend the meeting and give a chance for folks to ask for additional time if needed.
Based on yesterday's feedback. we updated the release page to the following schedule: http://www.ovirt.org/OVirt_3.5_release-management If check the history you'll see that the GA date is the same.
Ok. We postpone. But do we shed any feature? What should we focus on? I'm not into blaming the late features and their owner - I just want to know what are the real blockers.
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 5:58:01 PM Subject: Re: [ovirt-devel] 3.5 Time-frame: pushing feature freeze
On Thu, May 29, 2014 at 10:49:55AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 5:32:20 PM Subject: Re: [ovirt-devel] 3.5 Time-frame: pushing feature freeze
On Thu, May 29, 2014 at 09:10:59AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message ----- > From: "Livnat Peer" <lpeer@redhat.com> > To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, > devel@ovirt.org > Sent: Thursday, May 29, 2014 3:21:26 PM > Subject: Re: 3.5 Time-frame: pushing feature freeze > > On 05/28/2014 06:01 PM, Doron Fediuck wrote: >> Hi, >> The current date for feature freeze is May 30. >> Based on today's weekly sync[1], it seems that most teams require >> additional 2 weeks to conclude current work. >> >> Therefore I suggest to set an updated FF milestone for June 15. >> >> If you need more time or think we should not change the current >> date please respond. >> > > I think we should prioritize schedule over capacity. > Features which do not make it to FF can wait for the next release. > > I think that we should be more careful in the planning phase > because > it > seems to be a recurring phenomena where people commit for features > they > know won't make it to FF - still these features get approved for > the > release. > > I suggest to adopt a spec review phase, which would become part of > the > planning phase, Here is the process (which is similar to some of > the > openstack projects' process): > > 1. For each feature the owner would have to submit a spec file > which > includes a description and details of the feature (like what > feature > pages should include today - and mostly do not!). > > An example would be - > https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs... > > 2. The specs are getting reviews and hopefully approved after they > meet > some standards and make sense to add to oVirt. > > 3. Once a spec is approved it can be a candidate to include in the > release ( at this point the owner should have a good estimation on > how > long it is going to take him to implement the proposed spec) > > 4. The release manager of the version should approve the spec for > the > version according to the well known deadlines. > > > Livnat > >> Thanks, >> Doron >> >> [1] >> http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
And I agreed we will not be flexible for next version, but currently most teams are not ready yet. This is the feedback we got in the sync meeting and it cannot be ignored.
I don't think anybody suggests to ignore the feedback. As always, the question is: is the release time-based, or feature based?
It is not clear to me which are the features that block the release. They should be named and prioritized. Otherwise, we'd slip dates forever.
The number of non-green features in the spreadsheet http://bit.ly/17qBn6F does not match the numbers cited during the sync meeting, so I am confused.
On Vdsm side I find 5 features with code in advanced stages. jsonrpc and import data domain should probably block the release. I am not sure about the rest.
infra 1079821 [RFE] Prevent host fencing while kdumping Code will be in by end of May infra 1081049 [RFE] replace XML-RPC communication (engine-vdsm) with json-rpc based on bidirectional transport End of May infra 1083645 [RFE][scale]: Replace the use of oop with ioprocess Code will be in by Mid June virt 1082479 disable spice file transfer & copy and paste packaging on F19&F20 issues storage 1083307 import existing data domain coding
==================================
Can we agree on a definite list of feature that must block 3.5?
gluster 1040795 Gluster Volume Capacity monitoring In Progress gluster 1083583 Gluster Profile In Progress
infra 1063095 [RFE][AAA] engine should have a generic LDAP provider Most code already in. Finalization and fixes by mid June infra 1090517 [RFE][AAA] Support anonymous bind for authn/authz Most code already in. Finalization and fixes by mid June infra 1090515 [RFE][AAA] Support for "hardened" AD environments with oVirt Most code already in. Finalization and fixes by mid June infra 1083993 [RFE] using foreman provider to provision bare-metal hosts Code will be in by end of May
infra-cli 855724 [RFE] ovirt-engine-restapi : Statistic values representation issues In Progress infra-sdk 1069204 [RFE] Don't require live engine to generate SDK code In Progress integration 1080402 Allow setup of iSCSI based storage for hosted engine In Validation integration-dwh 1080997 DWH running on separate host In Progress integration-reports 1080998 reports running on separate host In Progress integration 1080992 websocket proxy running on separate host In Validation
storage 1083310 live merge (delete snapshot) coding storage 1058160 VM Async Tasks via HSM coding storage 1055640 Get rid of storage pool metadata on master storage domain code review (90% complete) storage 1086178 SANlock fencing design
virt 1083059 "Instance types (new template handling) - adding flavours" few things needs to be finished(perms,defaults,REST) virt virtio-rng support on review virt - finish remaining PPC support (block/allow specific features) on review
node 875088 ovirt-node-registration - a generic node registration ETA end of May (in review) node 1038616 ovirt node support for hosted engine nodes ETA end of May (in review) node 1053435 oVirt virtual appliance In progress
sla 1036731 hosted engine on iscsi In progress- should be ready by Mid June sla 1084930 CPU SLA for capping In progress- should be ready by Mid June sla 1085049 I/O SLA for capping (blkio) In progress- should be ready by Mid June sla 1093051 Integrating with Opta Planner to demonstrate a balanced cluster In progress- should be ready by Mid June sla 1069303 NUMA support in oVirt In Progress- missing UI and REST. sla 1062435 Implement REST API for oVirt scheduler In progress- should be ready by 1st week of June sla 1093038 Resource considerations for Migration in RHEV - memory Won't make it. sla 1093102 Reducing HA down-time In progress- should be ready by Mid June
Dan this is why we have the sync meeting, and this is where we discuss these issues as you know. There's no point of opening this now as the question is how much time we need to postpone and not if we wish to postpone.
The suggestion is for June 15 and it seems to be acceptable to everyone attended the meeting yesterday. This mail was to give a headsup for those who did not attend the meeting and give a chance for folks to ask for additional time if needed.
Based on yesterday's feedback. we updated the release page to the following schedule: http://www.ovirt.org/OVirt_3.5_release-management If check the history you'll see that the GA date is the same.
Ok. We postpone. But do we shed any feature? What should we focus on? I'm not into blaming the late features and their owner - I just want to know what are the real blockers.
We have a plan for 3.5, and anything in the plan which makes it to June 15 can be included. You have a valid point on blocking features and I'll open another thread asking folks to add it to the 3.5 tracker- http://bugzilla.redhat.com/1073943
Il 29/05/2014 16:32, Dan Kenigsberg ha scritto:
On Thu, May 29, 2014 at 09:10:59AM -0400, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 4:05:45 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/29/2014 03:44 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com>, board@ovirt.org, devel@ovirt.org Sent: Thursday, May 29, 2014 3:21:26 PM Subject: Re: 3.5 Time-frame: pushing feature freeze
On 05/28/2014 06:01 PM, Doron Fediuck wrote:
Hi, The current date for feature freeze is May 30. Based on today's weekly sync[1], it seems that most teams require additional 2 weeks to conclude current work.
Therefore I suggest to set an updated FF milestone for June 15.
If you need more time or think we should not change the current date please respond.
I think we should prioritize schedule over capacity. Features which do not make it to FF can wait for the next release.
I think that we should be more careful in the planning phase because it seems to be a recurring phenomena where people commit for features they know won't make it to FF - still these features get approved for the release.
I suggest to adopt a spec review phase, which would become part of the planning phase, Here is the process (which is similar to some of the openstack projects' process):
1. For each feature the owner would have to submit a spec file which includes a description and details of the feature (like what feature pages should include today - and mostly do not!).
An example would be - https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs...
2. The specs are getting reviews and hopefully approved after they meet some standards and make sense to add to oVirt.
3. Once a spec is approved it can be a candidate to include in the release ( at this point the owner should have a good estimation on how long it is going to take him to implement the proposed spec)
4. The release manager of the version should approve the spec for the version according to the well known deadlines.
Livnat
Thanks, Doron
[1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
Livnat, it seems that most other teams need the extra time based on yesterday's weekly sync, which included a network representative as well. So regardless of networking the rest of the version is not ready to freeze hence this is needed.
This is not about a specific team status, this is more about our general approach to deadlines which should be less flexible.
And I agreed we will not be flexible for next version, but currently most teams are not ready yet. This is the feedback we got in the sync meeting and it cannot be ignored.
I don't think anybody suggests to ignore the feedback. As always, the question is: is the release time-based, or feature based?
It is not clear to me which are the features that block the release. They should be named and prioritized. Otherwise, we'd slip dates forever.
The number of non-green features in the spreadsheet http://bit.ly/17qBn6F does not match the numbers cited during the sync meeting, so I am confused.
On Vdsm side I find 5 features with code in advanced stages. jsonrpc and import data domain should probably block the release. I am not sure about the rest.
infra 1079821 [RFE] Prevent host fencing while kdumping Code will be in by end of May infra 1081049 [RFE] replace XML-RPC communication (engine-vdsm) with json-rpc based on bidirectional transport End of May infra 1083645 [RFE][scale]: Replace the use of oop with ioprocess Code will be in by Mid June virt 1082479 disable spice file transfer & copy and paste packaging on F19&F20 issues storage 1083307 import existing data domain coding
Please add them to the 3.5 tracker bug (http://bugzilla.redhat.com/1073943)
==================================
Can we agree on a definite list of feature that must block 3.5?
gluster 1040795 Gluster Volume Capacity monitoring In Progress gluster 1083583 Gluster Profile In Progress
infra 1063095 [RFE][AAA] engine should have a generic LDAP provider Most code already in. Finalization and fixes by mid June infra 1090517 [RFE][AAA] Support anonymous bind for authn/authz Most code already in. Finalization and fixes by mid June infra 1090515 [RFE][AAA] Support for "hardened" AD environments with oVirt Most code already in. Finalization and fixes by mid June infra 1083993 [RFE] using foreman provider to provision bare-metal hosts Code will be in by end of May
infra-cli 855724 [RFE] ovirt-engine-restapi : Statistic values representation issues In Progress infra-sdk 1069204 [RFE] Don't require live engine to generate SDK code In Progress integration 1080402 Allow setup of iSCSI based storage for hosted engine In Validation integration-dwh 1080997 DWH running on separate host In Progress integration-reports 1080998 reports running on separate host In Progress integration 1080992 websocket proxy running on separate host In Validation
storage 1083310 live merge (delete snapshot) coding storage 1058160 VM Async Tasks via HSM coding storage 1055640 Get rid of storage pool metadata on master storage domain code review (90% complete) storage 1086178 SANlock fencing design
virt 1083059 "Instance types (new template handling) - adding flavours" few things needs to be finished(perms,defaults,REST) virt virtio-rng support on review virt - finish remaining PPC support (block/allow specific features) on review
node 875088 ovirt-node-registration - a generic node registration ETA end of May (in review) node 1038616 ovirt node support for hosted engine nodes ETA end of May (in review) node 1053435 oVirt virtual appliance In progress
sla 1036731 hosted engine on iscsi In progress- should be ready by Mid June sla 1084930 CPU SLA for capping In progress- should be ready by Mid June sla 1085049 I/O SLA for capping (blkio) In progress- should be ready by Mid June sla 1093051 Integrating with Opta Planner to demonstrate a balanced cluster In progress- should be ready by Mid June sla 1069303 NUMA support in oVirt In Progress- missing UI and REST. sla 1062435 Implement REST API for oVirt scheduler In progress- should be ready by 1st week of June sla 1093038 Resource considerations for Migration in RHEV - memory Won't make it. sla 1093102 Reducing HA down-time In progress- should be ready by Mid June
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (4)
-
Dan Kenigsberg -
Doron Fediuck -
Livnat Peer -
Sandro Bonazzola