----- Original Message ----- > From: "Dan Kenigsberg" <dan...@redhat.com> > To: "Doron Fediuck" <dfedi...@redhat.com> > Cc: "Livnat Peer" <lp...@redhat.com>, board@ovirt.org, de...@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" <dan...@redhat.com> > > > To: "Doron Fediuck" <dfedi...@redhat.com> > > > Cc: "Livnat Peer" <lp...@redhat.com>, board@ovirt.org, de...@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" <lp...@redhat.com> > > > > > To: "Doron Fediuck" <dfedi...@redhat.com> > > > > > Cc: board@ovirt.org, de...@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" <lp...@redhat.com> > > > > > >> To: "Doron Fediuck" <dfedi...@redhat.com>, board@ovirt.org, > > > > > >> de...@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,n,z > > > > > >> > > > > > >> 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 _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board