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" <[email protected]> >>> To: "Doron Fediuck" <[email protected]> >>> Cc: [email protected], [email protected] >>> 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" <[email protected]> >>>>> To: "Doron Fediuck" <[email protected]>, [email protected], >>>>> [email protected] >>>>> 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
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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
